[00:02] <Meliboeus> and a way to integrate submodules
[00:05] <jelmer_> RAOF: s/bzr-git/bzr
[00:06] <jelmer_> Meliboeus: ... and unfortunately that requires nested tree support in bzr itself
[00:07] <RAOF> jelmer_: Does it really require full bzr support for that to pull a different HEAD from a git repository?  I don't care for colocated bzr branches, just for the ability to grab & push to different git branches.
[00:07] <Meliboeus> jelmter_: exactly :-(
[00:07] <Meliboeus> my words. I don't care if I loose the history on submodules...
[00:08] <jelmer_> ROAF: Yes, there needs to be a way to address colocated branches in the Bazaar UI and API
[00:09] <RAOF> Which is presumably not the same level of difficulty as _implementing_ colocated bzr branches, no?
[00:09] <AfC> jelmer_: but why? On the Bazaar user side of things, we know about keeping different branches in different directories. I can easily checkout ~/vcs/gtk+/master and ~/vcs/gtk+/release-2.18.0 into different branch directories.
[00:09] <AfC> [if I could just address the Git branch somehow]
[00:10] <RAOF> Actually, I guess after being able to address them actually having colocated bzr branches should be pretty trivial, right?
[00:10] <jelmer_> AfC: Yes, and the addressing a colocated branch is something that is in bzr core
[00:10] <jelmer_> AfC: s/is/needs to be/
[00:10] <AfC> jelmer_: oh.
[00:10] <jelmer_> AfC: That's the main thing bzr-git is waiting for, the Bazaar UI needs to know about colocated branches and needs to pass that information down in the API (which is implemented, among other things, by bzr-git)
[00:12] <jelmer_> RAOF: Yes, it's different from implementing colocated branches for native .bzr directories
[00:34] <jelmer_> perhaps this is actually a good topic for the sprint in january
[00:51] <poolie> bug 500000 has just come and gone
[00:51] <poolie> what a boring bug too
[00:52] <gutworth> don't worry
[00:52] <gutworth> there will be bug 6000000 and 70000000 and<PHONE_NUMBER>0000000000000000000000000
[00:52] <gutworth> bug 1
[00:52] <gutworth> hmm
[00:53] <gutworth> bug me not
[01:55] <poolie> spiv, do you know about https://bugs.edge.launchpad.net/bzr/+bug/499817
[02:17] <pickscrape> Hi, I'm using bzr-svn for the first time with google code and am finding that I'm being asked for my username and password for every operation that interacts with the repository
[02:17] <pickscrape> I'm running bzr 2.0.3 and bzr-svn 1.0.0 on a karmic system.
[02:18] <pickscrape> I've found one bug that looks related but it's on an OSX system and talks of the OSX keychain, so I'm not sure how relevant it is.
[02:41] <jelmer> pickscrape, hi
[02:42] <jelmer> pickscrape: bazaar does not cache passwords yet
[02:42] <jelmer> pickscrape: neither for bzr-svn nor for bzr itself
[02:43] <jelmer> pickscrape: you can add a password manually in ~/.bazaar/authentication.conf
[02:44] <Peng> jelmer: I'm never actually going to get around to it, but hypothetically, would you mind if I stole bzr-svn's caching code for Loggerhead? :D
[02:48] <jelmer> Peng: not sure I follow - how would you like to use bzr-svn's caching code?
[02:48] <jelmer> Peng: it's all quite svn-specific
[02:56] <Peng> jelmer: OK, maybe not much more than the open_tdb method, but that'd still be useful. :)
[03:02] <thewrath> hey all
[04:23] <pickscrape> jelmer: thanks
[06:11] <mtaylor> hey lovely people...
[06:12] <mtaylor> bzr: ERROR: exceptions.ValueError: unknown object type identifier 60
[06:12] <mtaylor> aroo?
[06:19] <Peng> That's a known and I think fixed bug.
[06:20] <poolie> mtaylor: bug 427736
[06:20] <poolie> fixed in 2.1.0b1 and 2.0.1
[06:21] <mtaylor> poolie: awesome.
[06:21] <mtaylor> chromakode: ^^^
[06:21] <poolie> you should really go to 2.0.4 or 2.1b4
[06:21] <poolie> uh
[06:22] <poolie> that would be 2.0.3 i guess
[06:24] <mtaylor> poolie: I hear grumbling that he was using 2.0.3 ... although what it really pointed out to me is that I needed to upgrade that branch. but just in case it's useful to you to know someone is experiencing it using 2.0.3
[06:24] <chromakode> I
[06:24] <chromakode> I'm that someone :)
[06:24] <mtaylor> it's chromakode !
[06:24] <poolie> hm
[06:24] <poolie> if that's true, please reopen the bug
[06:24] <poolie> it would be surprising
[06:25] <poolie> but, software is often surprising
[06:25] <chromakode> oh! it worked now!
[06:25] <mtaylor> chromakode: yay!
[06:25] <chromakode> perhaps lp lagged when he updated the branch
[06:25] <mtaylor> are you pulling from http:
[06:25] <mtaylor> ?
[06:25] <chromakode> no, lp:
[06:25] <poolie> but do you have an lp account?
[06:25] <chromakode> yes.
[06:25] <poolie> that can be either ssh or http
[06:25] <mtaylor> well, that will resolve to http if you haven't told it your launchpad login ... but i'm guessing if you've every pushed from there you have...
[06:26] <chromakode> it's over ssh
[06:26] <mtaylor> cool
[06:26] <mtaylor> yeah - I've been noticing a slight lag recently even over ssh
[06:26] <mtaylor> which I've found ... annoying
[06:26] <chromakode> what did you change, mtaylor?
[06:26] <mtaylor> chromakode: I upgraded the remote branches to --2a
[06:26] <chromakode> okay, so all hunky dory now :)
[06:27] <mtaylor> yup
[06:27] <chromakode> thanks poolie
[06:27] <mtaylor> thanks poolie !
[06:27] <poolie> you're welcome
[06:46] <spiv> poolie: no, I'm not sure what's going on with bug 499817.  I've left a small comment.
[06:46] <poolie> k
[06:46] <poolie> have a happy holiday, i'm off
[06:46] <spiv> poolie: you too :)
[06:49] <Kamping_Kaiser> would it be possible to customise bzr (bzr-email?) to email a specific address when a particular file changes?
[06:50] <Kamping_Kaiser> eg, debian/changelog
[06:57] <chromakode> happy holidays poolie
[06:57] <spiv> Kamping_Kaiser: I expect so
[06:57] <spiv> Kamping_Kaiser: some hacking required presumably
[06:58] <spiv> Kamping_Kaiser: or mail an address than runs a procmail recipe that greps the mail for the filename and remails accordingly ;)
[07:01] <Kamping_Kaiser> spiv: the last item sounds like more effort then learning python to do the hacking properly ;)
[07:01] <Kamping_Kaiser> thanks for the reply.
[09:08] <Kamping_Kaiser> what package would i look for pythons 'tests' module? none of the results for 'apt-cache search python tests' seems relevant. ( and its required for bzr selftest)
[09:19] <Peng> "tests" is?
[09:20] <Peng> There's bzrlib.tests, the stdlib's unittest, and very recent bzr.dev requires testtools, but I dunno about "tests".
[09:20] <Peng> Kamping_Kaiser: Ohhhh. I think that error comes from a plugin, trying to do a relative import of its own tests. IIRC it'
[09:21] <Peng> Kamping_Kaiser: s fixed in a newer version. You can also do "bzr --no-plugins selftest" to disable all plugins.
[09:22] <Kamping_Kaiser> Peng: so the bug is in the plugin?
[09:22] <Kamping_Kaiser> I'll try without plugins for now, thanks.
[09:22] <Peng> Kamping_Kaiser: Well you'd have to pastebin a traceback to be sure.
[09:23] <Peng> Kamping_Kaiser: But I remember a plugin being a source of that error. Like I said, IIRC it's been fixed.
[09:24] <Kamping_Kaiser> Peng: fastimport's redme suggests running 'bzr selftest fastimport', which is bombing out with:
[09:24] <Kamping_Kaiser> bzr: ERROR: No module named tests
[09:24] <Kamping_Kaiser> You may need to install this Python library separately.
[09:24] <Kamping_Kaiser> so i assumed its a missing module ;)
[09:25] <Kamping_Kaiser> looks like all the plugins loaded are doing this, fwiw.
[09:25] <Peng> Kamping_Kaiser: Run with -Derror or check .bzr.log.
[09:26] <Peng> Kamping_Kaiser: It's probably because it's always loading all of the plugins' test suites, whether or not you're running them.
[09:26] <lifeless> Kamping_Kaiser: I'd guess fastimport's setup.py doesn't install the tests subpackage.
[09:26] <lifeless> Kamping_Kaiser: or one of your plugins doesn't.
[09:27] <Peng> Kamping_Kaiser: "bzr selftest -s bp.fastimport" should avoid loading any unnecessary tests.
[09:28] <Peng> Are the prefix aliases documented anywhere?
[09:29] <Peng> (I got "bp." by reading bzrlib/tests/__init__.py...)
[09:29] <Peng> Anyway, bye!
[09:29] <Kamping_Kaiser> thanks mate
[09:30] <Kamping_Kaiser> lifeless: looks like its the cia plugin - 'bzr selftest -s bp.fastimport' runs fine, ' bzr -Derror selftest launchpad 2>&1 |pastebinit -' bombs out with http://pastebin.com/f231eb61f
[09:30] <Kamping_Kaiser> i could believe it, cia stoped working for me a month or so ago.
[09:31] <lifeless> Kamping_Kaiser: cia !- launchpad
[09:31] <lifeless> Kamping_Kaiser: file bugs1
[09:31] <lifeless> !
[09:31] <Kamping_Kaiser> lifeless: on the cia blowing everything up, or everything else blowing up over cia?
[09:31] <Peng> Kamping_Kaiser: FWIW, "bzr selftest foo" builds a list of all tests, and then filters it. "bzr selftest -s bzrlib.foo" just loads the tests starting with that prefix.
[09:32] <Kamping_Kaiser> nod
[09:33] <lifeless> Kamping_Kaiser: both.
[09:33] <lifeless> Kamping_Kaiser: both are cia bugs I suspect.
[09:35] <jelmer_> Kamping_Kaiser, you're running an old version of bzr-cia
[09:35] <Kamping_Kaiser> jelmer_: ok, i'll get a new branch
[09:40] <Kamping_Kaiser> jelmer_: ftr, the readme should probably suggest using the name 'cia' instead of letting me assume 'bzr-cia' will work ;)
[09:46] <Kamping_Kaiser> jelmer_: thanks for the heads up re: version. launchpad selftets ok again, so cia's test failures are its own problem now :)
[09:51] <lifeless> ngnight
[09:52] <jelmer_> g'night lifeless
[09:53] <Kamping_Kaiser> later mate
[12:59] <rubbs> good morning #bzr
[13:01] <thewrath> good morning
[13:01] <thewrath> hey rubbs could you do me a favor?
[13:01] <rubbs> I will do my best. what's up?
[13:02] <rubbs> sorry, wrong button. I accedentally quit. If you said something before this (other than asking for help) I missed it
[13:02] <thewrath> could someone go to here http://csse.usc.edu/research/CODECOUNT/ and download the 2009.10 and try to compijle it for me
[13:03] <thewrath> 08:02 <+thewrath> i want to see if you are getting the same error
[13:03] <thewrath> it is c++ code
[13:03] <rubbs> sure... just a sec.
[13:03] <thewrath> thank you so much
[13:03] <Peng> rubbs: fwiw, you did not miss anything
[13:04] <rubbs> Peng: thanks.
[13:05] <thewrath> thank you rubbs
[13:12] <rubbs> thewrath: ok, compiling now.
[13:12] <rubbs> sorry for taking a while... slow connection
[13:12] <thewrath> okay
[13:13] <thewrath> tell me if you get a .exe file
[13:13] <rubbs> k... I"m on Linux, so I'll get an executable, but it won't be an .exe file.
[13:14] <thewrath> you sure?
[13:15] <rubbs> yeah, I'll get an executable... but that executable won't work on Windows. If you need a windows binary... I'll see what I can do. I have a windows environment lying around
[13:17] <rubbs> thewrath: this is the error I get: http://paste.ubuntu.com/345904/
[13:18] <thewrath> so you dont have an executable?
[13:18] <rubbs> no. no executable
[13:20] <maxb> Are there any existing tools for rewriting branches off of a mainline, after said mainline has been replaced with one with different revids and fileids?
[13:22] <rubbs> maxb: I'm not sure I understand. You have a main branch that you rewrote (possibly with rebase or something) and you want your other branches to reflect that?
[13:22] <maxb> essentially
[13:23] <maxb> Actually I had a main branch reflecting Ubuntu development that I synthesized, and now there is an official Ubuntu package branch
[13:24] <rubbs> are these branches just going to be mirrors? or are you trying to keep changes in the branches while changing their history?
[13:24] <maxb> I want to keep changes
[13:24] <maxb> I realize this is a hard problem :-)
[13:25] <maxb> However, I can probably hack bzr-rewrite into doing what I want, if there isn't a suitable tool already in existence
[13:26] <rubbs> maxb: I'll admit that this problem is a little bit out of my expertise (sp?) range.
[13:26] <rubbs> how many revisions are you wanting to keep in the branches?
[13:27] <maxb> not that many, but I'd rather not recommit them manually
[13:27] <maxb> I guess I'll hack on bzr-rewrite a bit
[13:27] <rubbs> sorry, I couldn't help more.
[13:30] <thewrath> rubbs: i have an older version i am going to check out
[13:31] <rubbs> thewrath:  2007?
[13:33] <thewrath> UCC v.2009.01
[14:18] <thewrath> rubbs: you still around
[14:18] <thewrath> if so what was that link you sent me
[14:19] <rubbs> I'm around... just a sec I'll dig it up
[14:19] <rubbs>  http://paste.ubuntu.com/345904/
[14:20] <thewrath> okay i got cygwin working with c++
[14:20] <thewrath> i got the same error thank you
[14:20] <thewrath> i will report it to the usc code count people
[14:21] <rubbs> cool
[14:21] <rubbs> glad to have helped
[18:24] <ruki> when i  upload to a branch on launchpad. does it replace the old copy of the file with the new one? cant i access my original old file?
[18:54] <gutworth> ruki: bzr cat -rold_rev myfile
[20:24] <nekohayo> hey there, if someone has a branch where he pushed a ton of commits of unrelated features (instead of making separate branches out of them), when merging, is it better to cherry-pick and do multiple merges?
[20:30] <gutworth> your choice really
[21:27] <nekohayo> ok
[21:28] <nekohayo> thanks :)
[21:56] <Tiibiidii> hi, i'm new to bazaar... it's better to keep versioned only the source directory for my projects, or it's better to keep versioned my entire IDE's workspace?
[21:57] <Tiibiidii> afaik bazaar should get along fine with binary files, but i've never done any versioning, and so i'm not sure if it's too much of a overhead
[22:08] <awilkins> Tiibiidii, I tend to work out which files it can regenerate and ignore them
[22:08] <Tiibiidii> it <-- do you refer to the IDE?
[22:08] <awilkins> e.g. - if I'm using Eclipse and / or Maven I ignore things like bin/ target/ .metadata/
[22:09] <awilkins> Ye
[22:09] <awilkins> Yes
[22:09] <Tiibiidii> mhn
[22:09] <Tiibiidii> shouldn't it be easy to version only the src files thus?
[22:09] <awilkins> And your IDE project file, if it uses such a thing
[22:09] <Tiibiidii> i mean: that way i should have to exclude manually the bin/ folder for every project
[22:10] <awilkins> For Java I'm using Maven and that will regenerate an Eclipse project
[22:10] <Tiibiidii> (sorry the dumb question: as i said i'm new)
[22:10] <awilkins> Tiibiidii, I think there may be a default list of includes you can configure
[22:12] <awilkins> .. or maybe not
[22:12] <awilkins> The main problem with versioning binaries is the inevitable conflicts
[22:13] <awilkins> e.g. - Visual studio timestamps binaries, so you NEVER get the same file twice, even with the same sources
[22:13] <Tiibiidii> mhn
[22:13] <awilkins> And of course, they are large, and unnecessary because you have the sources
[22:16] <Tiibiidii> so, i think i'll version only the src/ directories
[22:16] <Tiibiidii> awilkins, can i ask you another thing?
[22:16] <awilkins> Sure
[22:16] <Tiibiidii> if i'm not wrong
[22:16] <Tiibiidii> there's a bzr command to rename a file/dir
[22:17] <Tiibiidii> what happens if i rename that file manually?
[22:17] <gutworth> bzr can guess that you did
[22:17] <gutworth> usually
[22:17] <awilkins> It will lose track of it.. this happens in other VCS systems too (except git).
[22:17] <awilkins> There's `bzr mv --auto`
[22:17] <awilkins> Which guesses
[22:18] <awilkins> And `bzr mv foo bar --after` if you want to be explicit
[22:18] <Tiibiidii> should i use `bzr mv --auto` after a manual move/rename or before?
[22:18] <awilkins> After
[22:18] <Tiibiidii> ok
[22:18] <awilkins> Before there's nothing for it to guess about :-)
[22:18] <Tiibiidii> and if i rename the directory back to the previous name?
[22:19] <Tiibiidii> and if i rename the whole versioned directory (which i guess contains some .bzr files)?
[22:19] <awilkins> Only the root directory contains a .bzr folder
[22:19] <Tiibiidii> (and thank you very much for the answers so far :D )
[22:19] <awilkins> It's not like SVN where there's a control dir in each directory
[22:19] <Tiibiidii> root? do you mean $HOME ?
[22:20] <awilkins> No, the root of the versioned tree
[22:20] <Tiibiidii> mhn
[22:20] <Tiibiidii> if i go to $HOME/whateverdirectory
[22:20] <Tiibiidii> and then
[22:20] <Tiibiidii> bzr init
[22:20] <Tiibiidii> and then
[22:21] <Tiibiidii> cd .. && mv whateverdirectory whateverdirectory2
[22:21] <Tiibiidii> whateverdirectory is the root, right?
[22:21] <kfogel> Tiibiidii: you should be fine; I don't think foo/.bzr knows foo's name
[22:21] <kfogel> you can rename, move it around, whatever
[22:22] <awilkins> Yup, confirm that
[22:22] <Tiibiidii> ok
[22:22] <kfogel> what *will* break is when you have branches inside a shared repository and you move them outside that shared repository
[22:22] <awilkins> The only problem you get is if you move a branch that a checkout is attached to
[22:22] <kfogel> Tiibiidii: but if you don't know what that means, don't worry about it
[22:22] <kfogel> Tiibiidii: what awilkins said :-)
[22:22] <gutworth> kfogel: how does emacs transition come?
[22:23] <Tiibiidii> ok, thanks... in fact i don't know yet what a checkout is :-)
[22:23] <gutworth> docs!
[22:23] <Tiibiidii> last question (i think):
[22:25] <Tiibiidii> if i move .bzr from the root to another (external from root) directory, does that dir becomes a new root and then bzr tries to guess the changes made to it?
[22:25] <awilkins> That will break stuff
[22:25] <gutworth> no, that will break
[22:25] <Tiibiidii> ok :D
[22:25] <kfogel> gutworth: arrrgh, waiting for a savannah.gnu.org admin to finally do https://savannah.gnu.org/support/index.php?107170
[22:25] <Tiibiidii> thank you again
[22:26] <kfogel> gutworth: IOW, it's going great, in the sense that we're ready to switch as soon as the admins pull the trigger; what's difficult is getting them to pay attention :-).
[22:26] <awilkins> If you need to nest your content deeper, create new folders to hold it then move the root level folders down into them
[22:26] <gutworth> I'm excited to push some emacs patches I've been cursing cvs with
[22:27] <kfogel> gutworth: there's some ticket where they asked for volunteer admins; I'm going to go chime in there and say I'll help.  Whatever it takes to get this moving :-).
 If you need to nest your content deeper, create new folders to hold it then move the root level folders down into them <-- thank you... actually my use case is a bit more silly: i kept backupped some old versions of my code, and so i'm trying to find a painless and effortless way to version these in a unique root :D
[22:27] <kfogel> abentley: mornin', sunshine
[22:27] <gutworth> good look ten
[22:28] <abentley> kfogel: good evening.
[22:28] <gutworth> kfogel: why do you need read-only cvs?
[22:28] <gutworth> couldn't you just impose a social block?
[22:29] <kfogel> gutworth: not reliable enough -- Emacs has hundreds of devs
[22:29] <gutworth> ah
[22:29] <awilkins> I agree, I had to migrate a CVS for about 20 users and the only way to stop them committing is to chmod -w the files into oblivion
[22:29] <kfogel> awilkins: :-)
[22:30] <awilkins> "Use the SVN repo dammit!"   "But, but, but CVS!!!"
[22:31] <awilkins> I shall face the same uphill struggle, no doubt, trying to get people to adopt DVCS systems
[22:32] <kfogel> awilkins: and CVS is a pretty easy transition -- no adjustment of mental model needed.
[22:32] <kfogel> dcvs is harder
[22:32] <awilkins> Yeah, it took me about 2-3 days to get my head around the fact that merge was suddenly not incredibly painful
[22:33] <awilkins> At least Bazaar allows them to pretend it's SVN
[22:33] <awilkins> If only TBZR was as mature as TSVN   (but if wishes were horses...)
[22:36] <awilkins> I'm stuck on one project that implements it's own DVCS system that's more like a patch-queue thing with no dependency management, stores changesets in Java BLOB files by shoving them into an SVN repo
[22:37] <awilkins> It's very Wrong
[22:38] <awilkins> It has a small excuse in that it started 5 years ago when git was in it's infancy... and the data it's versioning isn't source code, it's a graph of objects.
[22:38] <gutworth> haha
[22:39] <awilkins> But I sit there and think that plopping it into ordered plain text files gets you free DVCS support... and that making text files fast for read-operations (writes are relatively sparse) is less challenging than making the merge system it has work well
[22:40] <awilkins> 'tis only about 5M objects or so
[22:40] <awilkins> 1000 objects per file and you have a file tree that's reasonable on most OSs (even Windows/NTFS)
[22:42] <kfogel> awilkins: sounds like you're describing the architecture of most DVCSs anyway :-)
[22:43] <awilkins> kfogel, I did briefly think about trying to version the objects as 1st class objects in git by writing some new bits that didn't target the filesystem but the BerkeleyDB instance it's in... but I think it might challenge even git to be managing 5M discrete objects
[22:44] <awilkins> And would also challenge me somewhat to write it :-|
[22:44] <kfogel> awilkins: I dunno, it's supposed to be pretty scalable.  Now, on the other hand, it might challenge the local filesystem to do that :-).
[22:44] <awilkins> NTFS would curl up and die
[22:45] <awilkins> Small files get inserted into the Master File Table
[22:45] <awilkins> You'd have to custom-format a partition for it
[22:45] <awilkins> Even then I think it would suck
[22:45] <awilkins> It's happy enough with 7000 files, my other project (the one that's successful) is working on trees that size
[22:46] <awilkins> They could do with better merging... it's XML model files and line-based merging gets a bit confused sometimes
[22:47] <awilkins> But that's  a job for when I have time
[22:48] <Tiibiidii> uhm... can i ask a question?
[22:48] <Tiibiidii> i did a commit
[22:48] <Tiibiidii> it said:
[22:49] <Tiibiidii> modified geotag/GeoApplication.form, modified geotag/GeoApplication.java
[22:49] <Tiibiidii> , etc.etc.
[22:49] <Tiibiidii> but then
[22:49] <Tiibiidii> bzr status and bzr diff
[22:49] <Tiibiidii> print nothing
[22:49] <gutworth> that's because you commited something
[22:49] <awilkins> They report the differences between the current state and the last commit
[22:49] <gutworth> so there are no changes in your wc
[22:49] <awilkins> Since you just committed, that's zero
[22:50] <Tiibiidii> ahhh, ok
[22:50] <Tiibiidii> thanks
[22:50] <gutworth> I suggest you read the tutorial
[22:51] <Tiibiidii> yeah, i read only the 5 minutes introduction... ^^