[01:12] <abadger1999> hmmm... is there a common misconfiguration that can cause bzr push bzr+ssh://[..] to start up a bzr smart server listed in inetd?
[01:13] <jam> abadger1999: IIRC, bzr+ssh:// spawns a "bzr serve --inet ..." to tell the bzr serve process to communicate on stdin/out rather than starting a TCP server.
[01:13] <jam> It is just a flag.
[01:14] <abadger1999> ah.  Okay.
[01:14] <jam> Otherwise you would have to have inetd configured to connect to port 22 or so.
[01:14] <abadger1999> So I'm seeing something else.
[01:14] <abadger1999> Right now when I do bzr push, I am told that there's a lock already on the repo.
[01:15] <abadger1999> If I stop the request, kill the bzr server, and bzr break-lock on the remote repo and try again I get an exception: TooManyConcurrentRequests:
[01:16] <jam> hmm... I'm not sure about the TooMany...
[01:16] <jam> but it is a known bug for having to run "bzr break-lock" 2 times
[01:16] <abadger1999> Okay.  So I should try running break-lock twice in the repo and see if it works?
[01:16] <jam> abadger1999: yeah
[01:16] <jam> the service that is still running is waiting to grab the lock
[01:17] <jam> so you want to break the lock, let it grab it, and then break it again
[01:17] <abadger1999> If I check and make sure that bzr serve isn't running on the server, that should be good too, correct?
[01:17] <jam> it *should*
[01:18] <jam> But you may need to break the lock after you ensure that
[01:18] <abadger1999> Okay.
[01:19] <abadger1999> So that takes care of the locks but I get the exception again: TooManyConcurrentRequests: The medium '<bzrlib.smart.medium.SmartSSHClientMedium object at 0x2aaab23b8790>'
[01:20] <jam> abadger1999: first, make sure sftp:// still works
[01:20] <jam> bzr log sftp://... is usually what I use
[01:20] <jam> (I wonder if you aren't mis-typing the host)
[01:20] <abadger1999> sftp won't work.
[01:20] <abadger1999> We have ssh access but not sftp.
[01:20] <jam> really, that is uncommon
[01:20] <abadger1999> Here's the full traceback: http://pastebin.ca/815408
[01:21] <abadger1999> It's for security reasons on this host.
[01:21] <abadger1999> ssh is locked down to only allow certain SCMs to be run on certain directories.
[01:21] <jam> abadger1999: well 0.91, I believe, didn't have the fixes to get better errors
[01:21] <jam> but it sure looks like the connection is closing down too quickly
[01:22] <abadger1999> Will the bzr on the repository leave better information?  Or do I need to update the clientside to get better errors?
[01:23] <jam> actually, it looks like the server side is dying
[01:23] <jam> #
[01:23] <jam>   File "/usr/bin/bzr", line 117, in ?
[01:23] <jam> #
[01:23] <jam>     sys.stdout.flush()
[01:23] <jam> #
[01:23] <jam> ValueError: I/O operation on closed file
[01:23] <jam> ^- That looks like the server side is trying to flush
[01:24] <jam> (flush stdout)
[01:24] <jam> but it has already closed
[01:24] <jam> I could be wrong.
[01:24] <jam> abadger1999: the client is generating the local traceback which is confusing because you aren't getting ConnectionClosed
[01:24] <jam> (instead you are getting TooMany...)
[01:25] <abadger1999> jam: here's the .bzr.log from the server: http://pastebin.ca/815414
[01:35] <abadger1999> jam: Interesting.  So it's something about the particular set of changes that I'm attempting to push that's causing this.  I made a new branch of the repo and was able to make a trivial change and push that back to the server.
[01:35] <jam> that is strange
[01:35] <jam> I'm afraid I'm not really sure what is going on off-hand
[01:36] <jam> I can come back to it tomorrow if you are still running into it
[01:36] <abadger1999> Should I make copies of my local and remote repositories for you guys before I try harder to fix this?
[01:36] <spiv> abadger1999: Perhaps try running the client with "-Dhpss", to put more debugging in the .bzr.log.
[01:36] <spiv> abadger1999: although I'm not sure it'll reveal much in this case
[01:36] <jam> you can, it seems more like just upgrading to something newer than 0.91 would also be a good step
[01:36] <spiv> I'd definitely try upgrading, yeah.
[01:37] <abadger1999> spiv: hpss shows the same thing.
[01:38] <abadger1999> Interestingly, the remote repo has now diverged from my local one so whatever is happening happened before that check is performed.
[01:38] <abadger1999> Creating a 1.0rc3 package for this box now.
[01:52] <abadger1999> spiv, jam: More output but same error with 1.0rc3:  http://pastebin.ca/815439
[01:55] <spiv> abadger1999: could you try "bzr -Dhpss push", and pastebin the relevant ~/.bzr.log excerpt that it generates?
[01:58] <abadger1999> spiv: http://pastebin.ca/815446
[02:01] <spiv> abadger1999: Hmm, so it successfully takes a lock on the repository, but fails on the first operation that actually tries to write to the repo.
[02:02] <Peng> What's with the TooManyConcurrentConnections exceptions? It happens a lot, when it doesn't make sense.
[02:03] <spiv> Peng: the smart client is a bit too easily confused when something unexpected happens.
[02:04] <Peng> Like the TooMany... exception is in an "else:" or something.
[02:04] <spiv> Peng: not quite
[02:05] <spiv> Peng: for instance, what's happening here I think may be an error response to the 'append' call that the client doesn't expect.  The relevant function raises an error, and that triggers a "finally: foo.unlock()" somewhere.  But the previous request/response pair hasn't been fully read from the wire.
[02:06] <spiv> Peng: so TooManyConcurrentRequests gets raised.
[02:07] <abadger1999> Another data point -- I created a fresh branch in a non-repository location and merged the changes from the old local branch to the new local branch.  bzr commit and then bzr push.... the push fails in the same way.
[02:08] <Peng> spiv: Oh. Requests. As in trying to do things at once. Ok.
[02:08] <Peng> s/do/do two.
[02:08] <Peng> /
[02:08]  * Peng can't type.
[02:09] <spiv> abadger1999: hmm!
[02:11] <spiv> abadger1999: the permissions on the server-side seem normal?]
[02:11] <abadger1999> spiv: Yes and I have pushed a small change from a fresh branch since the problem started.
[02:12] <spiv> So it's something weird about that data.  Hmm.
[02:12] <abadger1999> Let me try a small change to the particular file that seems to be failing.
[02:13] <abadger1999> spiv: Ah ha!  it is a permissions problem.
[02:13] <spiv> abadger1999: oh ho!
[02:13] <abadger1999> It looks like the smart server doesn't set the sticky group when it creates a fresh directory in .bzr/repository/knits
[02:15] <abadger1999> So I suppose the question is whether it's supposed to or not.  I know sftp was broken in this regard but thought the smart server was supposed to fix this.
[02:15] <spiv> The smart server doesn't explicitly set a umask.
[02:16] <spiv> So it will be inheriting whatever the default is I guess.  If the mkdir from the client side specifies a mode it should respect that though...
[02:18] <abadger1999> Well, umask should be 0002
[02:19] <spiv> abadger1999: http://pastebin.ca/815459 is the logic that should be used to choose the mode it uses
[02:24] <abadger1999> Well, that should find the correct mode.
[02:24] <spiv> Yeah, I think so too.
[02:24] <spiv> abadger1999: could you run a "bzr -Dhpss ..." that tries to create the .bzr/repository/knits directory, so we can see what mode the client asks for?
[02:25] <spiv> e.g. push to a new location outside of a repo should do it.
[02:29] <abadger1999> spiv: http://pastebin.ca/815470
[02:30] <abadger1999> We have to setup our repos with the sticky bit ordinarily though.
[02:30] <abadger1999> Want me to also push to an empty repo with the sticky group bit set?
[02:31] <spiv> Hmm!
[02:32] <spiv> For reference, the modes are sent in decimal over the wire for some reason.
[02:32] <spiv> 'mkdir', '/var/tmp/python-fedora-devel/.bzr/repository/knits', '509'
[02:32] <spiv> That's 0775
[02:32] <spiv> So the client is choosing the wrong mode it seems.
[02:34] <poolie> igc, hi
[02:34] <igc> hi poolie
[02:34] <poolie> someone pointed out that many links in http://bazaar-vcs.org/BzrUserGuide
[02:34] <poolie> are broken
[02:34] <poolie> can i just remove it now?
[02:35] <poolie> and redirect to the doc site?
[02:35] <igc> yes please
[02:35] <poolie> hm
[02:36] <abadger1999> spiv: Hmm.... but don't I need to have a directory or repository on the server that has the sticky group bit already set?
[02:36] <spiv> abadger1999: yes
[02:37] <poolie> spiv,  do you know anything about pqm
[02:37] <poolie> just for the guy asking on the list?
[02:37] <poolie> it's older than i am
[02:37] <poolie> at least, at canonical
[02:37] <abadger1999> I just set up a repository with permissions the way we set them up on the server and pushed to that.  That created a pack branch on the server instead of dirstate-tags but it set the sticky bit correctly.
[02:38] <spiv> abadger1999: Oh right, I see in that log the directories that bzr stat'ed didn't have sticky bits either.
[02:38] <abadger1999> Can I force it to use dirstate instead of pack when pushing to the remote repo?
[02:40] <abadger1999> Actually... I should be able to test this by creating a file and committing to the old repository right?  It'll create a new knit for the new file?
[02:40] <spiv> That's right.
[02:44] <abadger1999> spiv: Well... that was successful too.  I wonder if the person that committed the file is using a version of bzr with a bug (since fixed)
[02:45] <abadger1999> by successful I mean the new knit has the sticky group bit set.
[02:48] <spiv> abadger1999: yeah, I wonder that too.
[02:54] <abadger1999> Looks like that dev has gone home for the day.  I'll play around and see if I can find the problem version.  Hopefully it's something truly ancient :-)
[03:01] <spiv> poolie: Hmm, I don't know much about the nitty gritty of configuring it
[03:13] <poolie> igc, is there anything else to merge for 1.0?
[03:13] <igc> rst2html?
[03:13] <poolie> i have your cherrypicked fix for the download location
[03:13] <igc> it was from data actually
[03:13] <igc> s/data/dato/
[03:14] <poolie> well, rather the one you reminded me about
[03:15] <ubotu> New bug: #176263 in bzr "bzr rm \\ crashes with IndexError" [Medium,Confirmed] https://launchpad.net/bugs/176263
[03:15] <igc> poolie: looks like the rst2html fix is in 1.0 but not bzr.dev yet
[03:15] <poolie> ok
[03:16] <poolie> right, i'll merge back to dev soon
[03:16] <poolie> after the final
[03:16] <igc> sure
[03:42]  * igc lunch
[03:46] <poolie> ok, starting on the release now
[04:39] <MattCampbell> Is it feasible with Bazaar to combine the contents of multiple repositories into one, or split into multiple repositories?
[04:40] <MattCampbell> It doesn't seem possible to do this kind of reorganization with SVN without losing history.
[04:43] <poolie> can you explain more about what you want to do?
[04:44] <Peng> If they're two related branches, absolutely.
[04:51] <MattCampbell> I have two scenarios in mind.  First, suppose that I'm working on a large project, and I've developed a module as part of that project that is more widely useful, so I want to split it off without losing history thus far.
[04:51] <MattCampbell> Perhaps the larger project is proprietary, but I want to release the module as open source.
[04:52] <poolie> ok
[04:52] <poolie> so, bzr split helps with this
[04:52] <poolie> however, it'll still have a link back to the previous history
[04:52] <fullermd> Splitting is harder than combining.
[04:53] <poolie> and often if it was previously proprietary, people will want to make sure that's not exposed
[04:54] <MattCampbell> So if I think it might be desirable to release a piece of code as open source, then I should develop it in its own branch from the start.
[04:54] <poolie> yes, i'd recommend that
[04:55] <poolie> not just for vcs reasons, but also so you can be clear about what should or shouldn't be included in it
[04:55] <poolie> and what dependencies it can have on other things, or vice versa
[04:57] <MattCampbell> Now for the other scenario:  Suppose I have two different source trees "foo" and "bar", and I want to create a new bzr repository with these formerly separate trees as subdirectories (initially; once there's just oen tree, things can be moved around at will).  Can I do this while preserving the two histories thus far?
[04:58] <poolie> yes, bzr join does that
[04:58] <poolie> i should mention that this feature still has some rough edges
[04:58] <poolie> but if you want to give feedback and report some bugs, that would be great
[04:59] <MattCampbell> Thanks.  I'm evaluating bzr for use in a proprietary project that, to my shame, has not used any VCS at all thus far.
[05:00] <MattCampbell> though I've used CVS and SVN in some open-source projects.
[05:00] <poolie> bzr will be great :)
[05:00] <poolie> the amount of vcs knowledge needed is reasonably small...
[05:00] <poolie> so my main advice with this kind of splitting and joining is,
[05:01] <poolie> just to think about the issues beyond the vcs issues
[05:01] <poolie> dependencies between code and so on
[05:01] <poolie> keeping things separate is always easier than untangling them later
[05:01] <poolie> (assuming of course you know what should be separated)
[05:01] <poolie> btw, we just went 1.0!
[05:02] <MattCampbell> darn, my rc3, downloaded less than 2 hours ago, is already out of date. :)
[05:02] <poolie> there are no changes
[05:02] <poolie> aside from some doc corrections
[05:02] <poolie> but i'm happy to be here, i wanted to tell someone :)
[05:03] <Odd_Bloke> poolie: Congrats! :)
[05:06] <abadger1999> poolie: Woo hoo! Change the topic!
[05:07] <MattCampbell> Include the download URL.
[05:07] <MattCampbell> tarball URL, rather
[05:07] <Odd_Bloke> Moar bikeshedding! :D
[05:08] <abadger1999> Excellent!
[05:08]  * abadger1999 goes forth to make many many packages
[05:09] <spiv> \o/
[05:09] <poolie> ^5!
[05:10] <fullermd> Hm.  Well, that answers one question at least.
[05:10] <jml> wuuu
[05:10] <fullermd> FreeBSD ports freeze ended earlier this week.  I wondered which would happen first; they'd get around to committing the 0.92 update I submitted during it, or 1.0 would come out.
[05:11] <MattCampbell> Anyone here know how quickly a new Gentoo ebuild will become available?  How about a package for Debian Etch?
[05:12] <poolie> i'm going to do a deb soon, which i hope will be buildable on etch
[05:14] <MattCampbell> I've just started learning about Bazaar tonight.  I think it's killer feature is support for multiple workflows.  I'll probably start with the serverless solo workflow, then move to centralized with offline commits.
[05:18] <poolie> i think so too
[05:18] <poolie> you should check out ian's "adaptive vcs" paper
[05:18] <poolie> if you have not already
[05:19] <MattCampbell> URL?
[05:21] <poolie> http://ianclatworthy.wordpress.com/2007/10/11/why-distributed-version-control-matters/
[05:21] <poolie> hm
[05:21] <poolie> http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf rather
[05:22] <MattCampbell> Is the latter available in HTML?
[05:22] <poolie> maybe if you ping igc
[05:23] <MattCampbell> Never mind, I already have enough info to get started.  Thanks.
[05:24] <poolie> you're welcome
[05:24] <igc> MattCambell: would you like the OpenOffice original?
[05:25] <MattCampbell> don't have OO installed; I would prefer a conversion to HTML.
[05:25] <igc> no problem - I'll generate one
[05:26] <Peng> Ooh! I didn't know log had a --limit arg! Hg does, but with a -l abbreviation.
[05:26] <MattCampbell> (I have low vision, so I find HTML is easier to read in a large font or via speech synthesis if it's mostly prose. In case anyone was curious.)
[05:27] <poolie> peng, want to patch it?
[05:27] <poolie> except -l might be --long?
[05:29] <Peng> Nope, no such option! :)
[05:31] <Odd_Bloke> igc: If you make OO/text available, I'd be happy to make a LaTeX version.
[05:31] <Odd_Bloke> I take a perverse pleasure in writing LaTeX. :p
[05:32] <igc> Odd_Bloke: thanks. And good luck with that :-)
[05:33] <Peng> I shouldn't suggest it for 1.0, should I?
[05:33] <Odd_Bloke> Peng: It would be somewhat awkward to get it, if you examine the topic. :p
[05:34] <Peng> Woah!
[05:34] <Peng> I didn't notice!
[05:34] <Peng> Awesome!
[05:35] <Peng> Aww, I can't gpg-verify it. I can't get hkp keys.
[05:35] <Odd_Bloke> igc: I will need it in some format other than PDF (as pdftotext gives me "^L^L^L^L^L" and nothing else which, while easy to typeset, does not produce the strongest argument for DVCS :p).
[05:36] <MattCampbell> Why would you want to convert from ODF to LaTeX?
[05:36] <Peng> Congratulations!
[05:37] <Odd_Bloke> MattCampbell: Because ODF is fugly.
[05:41] <fullermd> Oh, you know those LaTeX people.  Buncha cultists.  They're almost as bad as the DVCS freaks.
[05:42] <Peng> packs, after repacking, in chronological order, in MB: 225, 11, 25, 78, 67.
[05:43]  * Odd_Bloke is a terrible, terrible person^W^W^W both.
[05:43] <Peng> I'm afraid to add that up.
[05:43] <fullermd> Peng: I think these days, that's roughly 18 cents   ;)
[05:44] <baijum> Congrats to all developers for 1.0 release !
[05:44] <Peng> Yeah, but like 150 MB of that is from the last month.
[05:47] <Peng> How are short names for args usually tested?
[05:48] <baijum> Is there any press release for 1.0 release ?
[05:49] <igc> MattCampbell, Odd_Bloke: My DVCS paper is now available in multiple formats here: http://people.ubuntu.com/~ianc/papers/
[05:49] <igc> Let me know if there are any problems
[05:50] <MattCampbell> Thanks.
[05:51] <ubotu> New bug: #176284 in bzr ""bzr plugins" should also display the plugin search path" [Undecided,New] https://launchpad.net/bugs/176284
[05:52] <MattCampbell> igc: One nitpick: The HTML version has no <title>
[05:52] <igc> Damd OOo - I'll add one by hand
[05:53] <igc> s/Damn/Damn/
[05:54] <MattCampbell> Also I think it's best not to specify font family and size in the CSS; users who want your exact formatting can get the PDF.
[06:16] <lifeless> glyph: bzr --version will tell you the search path
[06:16] <lifeless> I think
[06:17] <lifeless> hmm no. Well it should ;)
[06:20] <glyph> lifeless: heh heh
[06:24] <glyph> lifeless: well, *something* should, anyway - hence the suggestion ;)
[06:25] <glyph> and hey, uh
[06:25] <glyph> bzr: ERROR: Unrecognised value for BZR_SSH environment variable: C:/Program Files/Putty/plink.exe
[06:25] <glyph> what's up with that?
[06:25] <poolie> that's strange
[06:27] <poolie> glyph, I believe you're meant to use that to just say what type of ssh you want us to use
[06:28] <spiv> glyph: yeah, try just BZR_SSH=plink
[06:28] <poolie> so try just using "plink"
[06:28] <spiv> (and set your PATH appropriately, I guess)
[06:28] <glyph> bleh
[06:28] <poolie> that's kind of contradictory with how rsync and cvs use it
[06:28] <spiv> Different SSH programs take different command line arguments, which makes DWIM a little awkward.
[06:28] <glyph> I specifically *don't* have my PATH set, because I have 4 different plink.exe executables
[06:29] <poolie> hm
[06:29] <spiv> Possibily we should have separate BZR_SSH_EXE and BZR_SSH_TYPE variables.
[06:30] <poolie> i'm filing a bug
[06:30] <spiv> (Or maybe just rely on "if 'plink' in BZR_SSH:"?)
[06:30] <poolie> yeah
[06:30] <poolie> that should work
[06:31] <spiv> For plink at least.  I don't think we can disambiguate OpenSSH's ssh from SSH Corp's ssh that way.
[06:45] <ubotu> New bug: #176292 in bzr "BZR_SSH should allow setting the path to ssh, not just the kind of ssh" [Undecided,New] https://launchpad.net/bugs/176292
[06:45] <poolie> glyph, ^^
[06:45] <glyph> poolie: thanks
[06:46] <poolie> subscribe if you like
[06:46] <poolie> and please let us know if you hit something else
[06:46] <poolie> s//anything
[06:52] <Peng> With command arguments, are there unit tests for both --arg and -a or just one of them?
[06:53] <poolie> it varies
[06:53] <poolie> ideally, both would be tested
[06:53] <poolie> there is some work in test.command (iirc) towards testing command line parsing separately from the code that actually runs the command
[06:54] <Peng> I'm adding a -a for a command that already has a (tested) --arg already should I just add a new copy of the test, "test_command_arg_short" or something?
[06:54] <Peng> Oops, erase one of those "already"s.
[06:54]  * baijum just added release link to reddit: http://programming.reddit.com/info/62yy3/comments/ (I should have checked some other DVCS ;)
[06:55] <poolie> oops
[06:55] <poolie> but thanks for posting it there
[06:56] <baijum> np
[07:04] <ecognito> Hi.  If you have a shared repository that has been created with the --no-trees option, how do you figure out what it in there?  bzr ls only works on branches... I just have a folder with a .bzr sub-folder in it, but is otherwise empty...
[07:05] <Peng> What?
[07:06] <poolie> ecognito, try 'bzr info' on that directory
[07:10] <ecognito> It just says it is a shared repository.  It doesn't tell me what working trees I could pull out of it.
[07:10] <Peng> Ooh, I broke send!
[07:11] <Peng> Oh, never mind.
[07:11] <Peng> Well, send tracebacks when it's not in a branch, I guess.
[07:26] <nhaines> Congratulations on version 1.00!
[07:26] <poolie> thanks
[07:27] <Peng> bzr send tracebacks when used outside of a branch -> known bug?
[07:28] <poolie> i don't think so
[07:29] <poolie> ok, i'm going to take a break
[07:29] <poolie> See you later
[07:30] <jml> poolie: cya
[07:31] <jml> poolie: I'll hoist a pint for 1.0
[07:31] <poolie> cheers
[07:31] <poolie> me too
[07:32] <Peng> I'll hoist a pint of...water, if I can find a large enough glass. :)
[07:40] <ubotu> New bug: #176300 in bzr "bzr send tracebacks when used outside of a branch" [Undecided,New] https://launchpad.net/bugs/176300
[07:43] <igc> thanks and congratulations to everyone involved in delivering 1.0
[07:43] <igc> I'm off to celebrate my son's birthday so I won't be hanging around here tonight :-)
[07:44] <igc> cheers everyone
[07:44] <igc> night all
[07:44] <nhaines> Good night and congrats, igc :)
[07:44] <igc> thanks
[07:55] <MattCampbell> What's the difference between "bzr update" and "bzr merge", aside from "update" being more familiar to CVS and SVN users?
[07:57] <Peng> Using checkouts? I'm not sure.
[07:59] <nhaines> I think update only pulls from the checked-out repository, whereas merge has a lot more options and you can merge from any other branch.
[07:59]  * AfC never runs update and merge in the same branch
[08:00] <AfC> In fact, I never run update, but that's another story.
[08:03] <baijum> Hi AfC, during your FOSS.IN/2007 talk I installed bzr viz, and like it...thanks :)
[08:03] <AfC> baijum: :)
[08:03] <nhaines> I installed bzr viz just 30 minutes ago... and I like it.  :)
[08:04] <nhaines> I'm still a little more used to Subversion... but I could hardly escape the allure of running a VCS written in Python...
[08:04] <AfC> baijum: it's pretty sweet, although I've recently started realizing that what I really need is a unified cross between visualize, gannotate. I frequently find myself needing to study the evolution of code across revisions, and am trying to figure out what a UI to do that well would look like
[08:04] <AfC> nhaines: who cares what it is written in?
[08:05] <nhaines> AfC: I do, merely because I'm most proficient in Python and can therefore make changes and bugs if I need to.
[08:05] <AfC> One would have thought that "whether it works correctly or not" would be a more important criterion. {sigh}
[08:06] <nhaines> This is merely a secondary concern: if it didn't work, then of course it would have been right back to svn.  But being written in Python and used by some rather large projects was the draw.
[08:09] <nhaines> Freedom 1 can't be underestimated.
[08:10] <baijum> AfC, is olive does provide a single unified UI for all these functionalities ?
[08:11] <NamNguyen> awesome! 1.0 is out
[08:19] <nhaines> hmm, need to reboot.  bye, alll!
[11:44] <jelmer> ddaa: ping
[12:08] <LarstiQ> elmo: bazaar-vcs.org seems to be having problems?
[12:24] <sabdfl> Wooooot!
[12:24] <sabdfl> well done all
[12:26] <jelmer> thanks sabdfl :-)
[12:26] <jelmer> hey LarstiQ
[12:26] <LarstiQ> hey jelmer
[12:27] <jelmer> Riddell,luks: Just tracked down the memory leak in python-subversion. I've got a hack that works, hopefully something better later this week.
[12:27] <jelmer> Fetching revisions from KDE's history I've now got bzr using 20Mb RAM while it's already fetched metadat for 30krevisions
[12:28] <jelmer> (compared to 300Mb earlier)
[12:28] <Riddell> jelmer: ooh, exciting
[12:30] <dato> abentley: hi. it seems that http://panoramicfeedback.com/opensource/bzr/repo/plugins/bzrtools/ is missing revisions? (doesn't have an up to date version.py at least, it's at 0.92). is that still the current URL?
[12:34] <Peng_> When running "bzr status", does bzr read every file to see if it matches, or cache stat information or something?
[12:34] <Peng_> s/matches/has been changed/
[12:35] <Peng_> When running "bzr status", does bzr read every file to see if it has been changed, or cache stat information or something?
[12:45] <mwhudson> Peng: there is caching
[12:45] <ubotu> New bug: #176350 in bzr "gets confused when editor is killed" [Undecided,New] https://launchpad.net/bugs/176350
[12:47] <spiv> Peng: it stats, and compares to a cache of stat information.
[12:47] <spiv> Peng: that's the "dirstate" file.
[12:48] <spiv> jelmer: fantastic
[12:49] <Peng> Okies.
[12:49] <Peng> Hg does too.
[12:50] <Qhestion> hmm is it possible to write a bazaar plugin that implements a specific merging method for specific files?
[12:51] <jelmer> Qhestion: I believe Aaron has been working on support for that
[12:51] <jelmer> Qhestion: His nick on IRC is abentley, but he doesn't appear to be around
[12:52] <Qhestion> so i cant just hook into the merging method and..?
[12:52] <Qhestion> :(
[12:53] <jelmer> Qhestion: You can register a custom merging method I think, but that would be called for all files at the moment
[12:54] <Qhestion> well, that wont be a problem: i think it would be easy to check for a condition and call the original merging method if not true
[12:54] <jelmer> Aaron's work was focussed on merge algorithms for specific files I think (e.g. C-specific merges)
[12:57] <Qhestion> i will look into it, and if i get it to work put my branch somewhere. and with some luck it will get integrated into the the main bazaar branch :)
[12:58] <jelmer> Qhestion: well, that was the sort of thing Aaron was working on afaik so please coordinate with him if you intend on having this merged into mainline.
[12:59] <abentley> Qhestion: I'
[12:59] <abentley> I'm not working on it at the moment and haven't gotten very far anyway.
[12:59] <abentley> Feel free to proceed.
[13:10] <Qhestion> oh, bazaar 1.0 today!
[13:10] <Qhestion> good job!
[13:34] <jelmer> hi Aaron
[14:14] <fbond> Anybody know anything about 1.0 .debs maybe being published?
[14:16] <jelmer> fbond: .debs have been uploaded to Debian sid
[14:17] <jelmer> lifeless takes care of the Ubuntu and bazaar-vcs.org debs
[14:17] <jelmer> lifeless: ping
[14:35] <Peng> Darn, even with the bug-124089 branch that's working on bzr+http's path handling issues, it still gave me "not a branch".
[14:35] <Peng> Well, I might be using the wrong bzrlib.
[14:56] <vila> jelmer: lifeless is in vacation :)
[14:57] <jelmer> vila: well, he seems to be around sometimes
[14:58] <vila> true, but right now he may just be celebrating 1.0
[14:58] <Peng> That's a nice kind of vacation! Behave normally, but whenever someone asks you to do something you don't want to, just say "dude, I'm on vacation!".
[14:59] <fullermd> Heck, I do that pretty much all the time...
[14:59] <Peng> Heh.
[14:59] <fullermd> That's the advantage of taking your vacation time in 5 minute increments; you can go on vacation just long enough for somebody to get bored and wander off   ;)
[15:01]  * vila takes some vacations
[15:01] <Stavros> Hi, I'm new to bazaar and am trying it out, and I've noticed that when someone pushes their changes to my repo, bazaar automatically merges their changes to my working copy without notifying me. Is that safe?
[15:01] <Peng> Usually you mostly pull, not push.
[15:02] <Stavros> Oh hmm. I'm still getting the hang of DVCSs...
[15:02] <Stavros> How safe is automatic merging in general?
[15:03] <radix> Stavros: what's automatic merging?
[15:03] <radix> you mean what "bzr merge" does?
[15:03] <Stavros> Yes.
[15:03] <vila> Stavros: may be you're confusing branch and repo here, you can have a repo where everybody push (including yourself) and your own branch(es) as you're working env
[15:03] <Stavros> Well...
[15:04] <vila> s/you're/your/
[15:04] <Stavros> radix: I mean merging of the actual code between revisions.
[15:04] <Stavros> vila: Isn't a branch an entire repo in itself?
[15:04] <radix> Stavros: can you name specific bzr operations? because I don't really understand what you're saying
[15:04] <Peng> Stavros: I'd say "mostly safe", but it is possible to trick the algorithm (3-way merge) into doing things a little wrong, and two people can make incompatible changes to different sections of a file.
[15:04] <Peng> Stavros: I'd review it if I could.
[15:04] <Stavros> Peng: Ah, I see.
[15:04] <radix> Peng: it doesn't sound like he's actually talking about "merge"...
[15:04] <vila> Stavros: A branch use a repository to store the revisions
[15:04] <Stavros> radix: What Peng said, I'm talking about the merging of code in the files.
[15:05] <radix> Stavros: so you mean when you explicitly do a "bzr merge" operation, you're wondering if the algorithm it uses to merge the changes together is safe?
[15:05] <Stavros> radix: Yes, the same thing that bzr appears to do when pushing.
[15:05] <vila> Stavros: so I should have said: you can have a branch where everybody push (including yourself) and your own branch(es) as your working env
[15:06] <radix> Stavros: that's not what happens when you push
[15:06] <Stavros> vila: Ah.
[15:06] <Stavros> radix: Well, I just pushed my branch to another repo and it merged the repo's working copy with my changes.
[15:06] <radix> Stavros: pushing *only* works with non-diverged branches, so there's no actual merging happening -- just appending of revisions
[15:06] <fullermd> radix: It is when you locally push into a branch with colo'd working tree where somebody is working.
[15:06] <radix> Stavros: it didn't "merge", it just added some revisions
[15:06] <Stavros> radix: Ah, different terminology then.
[15:06] <Stavros> That's what I meant by merging, the actual changing of the file.
[15:07] <Stavros> Not the bzr "merge" operation.
[15:07] <fullermd> (not that that's a particularly sane workflow, but...)
[15:07] <radix> right, ok
[15:07] <Stavros> I see now though, thanks.
[15:07] <radix> Stavros: so that's very safe
[15:07] <radix> Stavros: as long as you don't use --overwrite, it won't affect the target branch in a bad way
[15:07] <radix> i.e., you can always back out those changes, or whatever.
[15:08] <radix> and if you don't want *other* people affecting your branch at all, well, don't give them write access.
[15:08] <Stavros> Yes, I suppose so. I was just worried that it could happen while I wasn't looking, since with SVN/whatever it would tell you that there are new changes and you'd have to merge and then commit.
[15:08] <radix> Stavros: then you need a different workflow
[15:08] <radix> Stavros: allow other people to publish branches somewhere else, but not push directly to your branch
[15:08] <radix> Stavros: and then you can merge them when you want
[15:08] <Stavros> radix: I was just testing and noticed that, I'll probably be using a SVNish model with a central server.
[15:08] <Stavros> Just for backup mostly, since I'm usually solo.
[15:09] <Stavros> I also tried Hg recently and liked it, so now I'm between these two systems, which are both very nice.
[15:28] <mwhudson> jelmer: that memory leak workaround is lovely :)
[15:29] <jam>  Stavros: so doing "bzr push .../existing-branch" is similar to if someone in svn did
[15:30] <jam> svn checkout .../existing-branch; change stuff; svn commit
[15:30] <jam> It only works if their changes are descended from your tip revision
[15:31] <jam> I would mention that when you "bzr merge" it *doesn't* automatically commit
[15:31] <jam> and both pull/push only work if there would be nothing to merge (eg someone has already done the merge)
[15:33] <luks> well, at least pull will try to merge uncommitted changes
[15:35] <Stavros> jam: Hmm, I don't think that example is accurate, because in bzr the person's changes are reflected in your working copy, while in SVN you get a notification that there were changes when you try to commit...
[15:36] <Stavros> I think that there might have been some danger where you'd be working on it, and commit only to find out that your working copy had changed incompatibly and you've checked in a broken build.
[15:36] <Stavros> But that's a pretty far-fetched usecase...
[15:36] <jam> Stavros: with SVN?
[15:36] <jam> or with Bazaar?
[15:37] <Stavros> jam: bzr, with SVN you get a notification, it doesn't change anything without you knowing.
[15:37] <jam> In bazaar you would have to bzr update
[15:37] <jam> And it wouldn't let you commit if you were out of date
[15:37] <jam> I'm not sure how it is doing what you suggest
[15:37] <Stavros> No, picture this:
[15:39] <Stavros> You pull my repo and work on feature B, and I work on feature A. I test feature A, and leave a touch for later. You test feature B and commit and push to mine. Your feature breaks mine, and bzr changes my working copy to implement your changes, and when I commit, it's broken.
[15:39] <Stavros> Unless I did something wrong?
[15:39] <jelmer> Stavros: in general, you don't push to somebody elses branch
[15:39] <jam> Stavros: when you push, how did you update the working tree?
[15:39] <jam> You might push to the *branch*
[15:39] <Stavros> jam: I didn't, it was already updated.
[15:39] <jam> but the WT knows it is out-of-date
[15:39] <jam> The only way I know to do that is to have both users working on the same machine
[15:39] <Stavros> Hmm, I'll retest it, maybe I made a mistake.
[15:40] <jam> and have them bzr push ../other-working-tree
[15:40] <Stavros> jam: I actually was :p
[15:40] <Stavros> I didn't think it'd matter, I was testing it out.
[15:40] <Stavros> So what does it do when you're on another machine?
[15:40] <jam> It marks the branch at a new point
[15:40] <jam> and your working tree stays put
[15:40] <Peng> Stavros: The usual workflow is to have the other person push somewhere, and you pull.
[15:40] <jam> (we don't update WT on another machine unless you have my push-and-update plugin installed)
[15:40] <Stavros> Ah, and you have to update as normal?
[15:41] <jam> correct
[15:41] <Stavros> Peng: Yes, that would be how I would normally work too...
[15:41] <Stavros> jam: Good, so I was seeing something else... It makes sense, really, too.
[15:41] <Stavros> You can push through ssh, right?
[15:41] <jam> Stavros: bzr+ssh or sftp
[15:41] <jam> yes
[15:41] <Stavros> What's the difference between those two?
[15:42] <jam> one spawns bzr over an ssh connection
[15:42] <jam> the other just uses an sftp server
[15:42] <jam> bzr+ssh is a bit faster, but requires you install something on the server
[15:42] <Stavros> So bzr+ssh is faster but needs bzr?
[15:42] <Stavros> Aha.
[15:42] <Stavros> I understand there's a plugin to push/pull from Hg as well?
[15:43] <Stavros> Why don't these two projects just merge and make my life easier :P
[15:43] <jam> there is bzr-hg, but I think it is limited to puling atm
[15:44] <jelmer> yes, it is
[15:44] <jam> Generally, we can represent hg metadata, but we have to shoehorn ours back into theirs
[15:44] <Stavros> Oh, hmm...
[15:44] <Peng> I need a shoe horn.
[15:44] <jam> bzr-svn is the only one that has gone to the effort of that
[15:45] <jam> it could probably be done
[15:46] <jam> but I don't know off-hand how to insert extra metadata about a revision into hg
[15:46] <Stavros> Is there any chance the two would merge?
[15:47] <luks> jam, hg has an equivalent of bzr revision properties
[15:47] <jam> luks: is that a newer thing?
[15:47] <Peng> Stavros: Well, they have entirely different codebases.
[15:47] <luks> no idea, I've only seen it in the code some time ago
[15:48] <Stavros> Peng: True, but they're very similar to what they do... It's a pity that you have to choose between programs that have 90% same functionality...
[15:48] <Stavros> similar *in* what..
[15:50] <jam> There certainly are similarities, we actually had a meeting together about 1.5y ago, but at that time both groups were pretty sure that their way was the Right Way...
[15:50] <jam> hg was focused on being a fast light system
[15:50] <jam> Bazaar didn't want to give up some of the abstractions
[15:50] <jam> (which makes it easy to support things like bzr-svn, bzr-hg, etC)
[15:50] <jam> etc
[15:50] <Stavros> Hmm, if it's a tradeoff, it'd be hard to reconcile...
[15:51] <Stavros> I work at most with a few MB of code, so I think I'll go with bzr...
[15:51] <jam> Some other small things, like whether "merge" should auto-commit
[15:51] <jam> We generally feel it is a bad idea
[15:51] <jam> to commit without human interaction
[15:51] <Stavros> Yes, I would agree.
[15:51] <Stavros> I don't even like automatic merging of the code :P
[15:51] <jam> Whether "merge" should make you resolve conflicts as they come
[15:51] <jam> Or whether you can do it after the fact
[15:52] <Stavros> How come bzr doesn't have a few critical parts written in C or such, for speed?
[15:54] <quicksilver> because the language they were written in wasn't obviously the speed problem :)
[15:54] <quicksilver> it was better to fix the algorithm...
[15:54] <Stavros> Ah, it's always good when you CAN fix the algorithm... Sometimes you just have to rewrite.
[15:55] <Stavros> Python's support for C modules is great, so it wouldn't be that hard anyway.
[15:56] <luks> bzr does have some parts written in pyrex and c
[15:56] <luks> but they are optional
[15:57] <LeoNerd> Besides.. I find bzr "fast enough" for my purposes
[15:57] <LeoNerd> Whereas, I'm impressed by the speed of the bzr developers. The reason they're that fast is they can write high-level python code, not low-level C code
[15:58] <LeoNerd> I'd rather wait an extra 5 seconds for "bzr shelve" to run, than wait an extra 5 months for the developers to first write it. :)
[15:58] <jam> Yeah, algorithm tweaking is a bit easier in Python
[15:58] <Stavros> I think you'd have to have a HUGE codebase to notice slowdowns in your VCS anyway, so it's not really an issue...
[15:58] <luks> I'm very often tempted to try to use hg or git, but it's hard if you are used to the comfort of bzr :)
[15:58] <jelmer> mwhudson: :-)
[15:58] <jam> And then once we figure out what is going on if we've reached a limit and it is a critical function
[15:58] <jam> we've written some Pyrex extensions, etc.
[15:58] <Stavros> What does "shelve" do?
[15:58] <Stavros> I can't find it in help"
[15:58] <jam> Pretty much all in the form of "if you have it compiled, use it, else use the python implementation"
[15:58] <jam> Stavros: it is from "bzrtools"
[15:59] <Stavros> Oh.
[15:59] <jam> It lets you put patches "on a shelf"
[15:59] <radix> Stavros: you're really going to have to come up with a better word than "merge" to describe that, since you're going to continue to confuse people :)
[15:59] <jam> The only reason it isn't core is because it relies on "patch" being available
[15:59] <jam> and because it doesn't handle binary files
[15:59] <LeoNerd> Actually, I find shelve needs some work
[15:59] <Stavros> radix: Where? I haven't said "merge" in ages :P
[15:59] <LeoNerd> shelve a change, then rename a file. You can't unshelve it without manual hackery within the shelf file
[16:00] <jam> Stavros: well, fixing the algorithm/fixing how you store data
[16:00] <radix> Stavros: I guess about a page up is "ages" :)
[16:00] <Stavros> radix: We have moved on, sir! :p
[16:00] <jam> LeoNerd: or make a trivial change to the file so it won't apply cleanly
[16:00] <Stavros> Seriously though, what's it called?
[16:00] <LeoNerd> That too
[16:00] <radix> Stavros: "pushing" :)
[16:01] <jam> luks: you're Lukáš L, right?
[16:01] <radix> Stavros: it's really just like any other upload or copy operation, it's just optimized so it doesn't transfer unnecessary revisions and doesn't allow you to do it if branches have diverged
[16:01] <luks> jam, yes
[16:02] <jam> It is always fun to submit your patches to PQM and watch the email interfaces choke on your name :)
[16:02] <luks> heh
[16:02] <radix> hehe
[16:02] <Stavros> radix: No, I'm talking about the actual changing of the file to put the changes from another file in it, regardless of a VCS context.
[16:02] <jam> luks: but at least we represent it properly in the commits
[16:02] <Stavros> radix: I.e. diff/merge, it's what it's called :P
[16:02] <radix> Stavros: then I still think you don't understand it
[16:02] <radix> Stavros: think about "cp fileA fileB"
[16:02] <Stavros> radix: I think we're talking about two different things.
[16:03] <radix> Stavros: I think we're talking about what happens when you do "bzr push <remote-URL>"?
[16:03] <Stavros> radix: No, we resolved that :)
[16:03] <radix> oh, whew.
[16:03] <Stavros> radix: It was because I was pushing on the same machine.
[16:03] <radix> sorry. I have only been half-paying attention.
[16:03] <Stavros> Shows! :P
[16:03] <radix> Stavros: oh, pushing on the same machine is basically the same as pushing to a remote machine.
[16:04] <Stavros> Now I'm confused again, then.
[16:04] <radix> Stavros: hooray! let's fix it :)
[16:04] <Stavros> Haha
[16:04] <jam> radix: if there is a local working tree
[16:04] <jam> we update it
[16:04] <Stavros> Okay, when I pushed to the other directory, the working copy was updated with the changes, without me updating.
[16:04] <jam> That is what Stavros was running into
[16:04] <radix> ahhh. ok. the orking tree updating.
[16:04] <radix> Stavros: so, yeah
[16:04] <Stavros> Ah. So is that it or not? :(
[16:04] <Stavros> Stop confusing me :P
[16:04] <jam> Stavros: local working trees are updated by push
[16:05] <radix> Stavros: ok, yes, so the working tree is updated when you push locally, HOWEVER
[16:05] <radix> 11:02 < Stavros> radix: I.e. diff/merge, it's what it's called :P
[16:05] <radix> Stavros: updating the working tree is still totally unrelated to stuff like diff and merge.
[16:05] <radix> Stavros: we can move back to my "cp" analogy again :)
[16:05] <jam> luks: are you 'luks' on LP?
[16:05] <Stavros> radix: I am talking about the verb "to merge", not the VCS operation "merge" :P
[16:05] <luks> jam, yes
[16:05] <jam> k
[16:05] <jam> just marking your bug as merged
[16:06] <radix> Stavros: even so. it's really just like "cp". except when you do it locally, not only are the low-level revisions copied, so are the working tree files.
[16:06] <jam> well marking Odd_Bloke's bug as fixed by you, and merged
[16:06] <Stavros> When you do a push on a local disk, it doesn't do a VCS "merge", but it does merge the changes into your working copy
[16:06] <luks> :)
[16:06] <Stavros> My connection is lagging somewhat, apparently, so what I say may appear out of context.
[16:06] <radix> Stavros: s'cool.
[16:06] <Stavros> radix: Yes, exactly.
[16:06] <radix> Stavros: anyway, I guess we're on the same page
[16:06] <radix> Stavros: I'll try to stop bugging you :)
[16:06] <jam> Stavros: well, when I switch to work on something else while chatting *I* lag a little bit
[16:07] <jam> so I don't really notice :)
[16:07] <Stavros> radix: It's ok :P
[16:09] <Stavros> ooo, graphs
[16:10] <Stavros> Hmm, so shelve is for when you want to fix something without losing the changes in your working copy?
[16:10] <Peng> It's for when you've made multiple unrelated changes and you only want to commit some of them.
[16:10] <radix> I guess it's really for any time you want to temporarily revert parts of your working tree.
[16:10] <Peng> Or when you want to put something aside.
[16:10] <radix> and yeah, committing parts of them is probably a main use case.
[16:11] <radix> (when the boundaries aren't aligned with files)
[16:11] <jam> Stavros: I personally use it when I'm working on a bug fix, and I've written a possible fix and some test cases
[16:11] <jam> and I want to make sure that the test suite *fails* without the patch
[16:11] <radix> ah, yes, it's a good thing to use when you (ahem) forgot to use TDD ;-)
[16:11] <jam> So I 'bzr shelve file', bzr selftest new-test, bzr unshelve; bzr commit
[16:12] <jam> radix: I use TAYD
[16:12] <Stavros> Aha... Couldn't you do sort of the same with pulling the latest commit into another branch and working on that?
[16:12] <jam> (test as you develop)
[16:12] <jam> Stavros: sure, there are other ways to do it
[16:12] <jam> it is just *fast* to put aside things for a quick second, and then bring them back
[16:12] <Stavros> Interesting tool, though. I should get it.
[16:12] <Stavros> Agree.
[16:12] <jam> you could do a partial commit
[16:12] <jam> and revert
[16:12] <jam> I've done that too
[16:12] <Stavros> Does it work well?
[16:12] <jam> shelve or commit+revert?
[16:13] <Stavros> shelve
[16:13] <jam> commit+revert handles more cases properly
[16:13] <jam> shelve generally works if the stuff is simple
[16:13] <Stavros> Yes, but sometimes you aren't done working on the thing so you can commit...
[16:13] <jam> Stavros: well, that is why branches are cheap
[16:13] <jam> you can also do partial commits
[16:13] <jam> etc
[16:13] <jam> Though "bzr commit" doesn't let you select specific hunks like shelve does
[16:14] <Stavros> Partial commits are only done with shelve, then?
[16:14] <jam> 'bzr commit file1 file2'
[16:14] <jam> won't commit changes to file3 4 or 5
[16:14] <jam> But committing selected *hunks* are done using shelve
[16:14] <Stavros> Good, that's a useful tool then.
[16:15] <jelmer> jam: is there something that allows you to commit just hunks?
[16:15] <jam> jelmer: not that I know of
[16:15] <Stavros> That would be a nice feature, instead of shelving the ones you DON'T want and committing...
[16:15] <jam> It would be a bit tricky considering our commit layering which likes to think of texts as snapshots
[16:15] <jam> So you would probably have to have a staging area to put the edited text, etc.
[16:15] <jelmer> yes, I agree
[16:16] <Stavros> Ah, hmm...
[16:16] <jam> You probably could keep the hunks in memory if you wanted
[16:16] <jelmer> jam: Since you can specify a tree to commit, shouldn't it be possible to just build a part-in-memory tree with the hunks you want?
[16:16] <jam> Since it is generally just use *these* lines or *these*
[16:16] <jam> jelmer: yeah
[16:16] <radix> jelmer: well, the thing about shelve is that it gives you a chance to run the tests after separating the changes.
[16:16] <Peng> (Hg has a record extension to commit hunks.)
[16:16] <Peng> (Like darcs record.)
[16:17] <jam> radix: thanks for pointing that out, too
[16:17] <jelmer> radix: That's a good point
[16:17] <jam> Stavros: that is probably the #1 reason we went with the shelve workflow
[16:17] <jam> since it lets you see the tree as it really is
[16:17] <jam> rather than how you *think* it would be with that patch removed
[16:17] <Stavros> jam: Yes, that would be much more useful...
[16:17] <Peng> ?
[16:18] <Stavros> Damn shortcuts...
[16:18] <Stavros> Where does shelve store its files?
[16:18] <jam> Peng: ? who are you questioning?
[16:18] <radix> (which is the same sentiment that makes me think it's a bad idea to review a branch as a diff of its base as opposed to as how it's merged)
[16:18] <jam> Stavros: .shelf/*
[16:18] <Stavros> Ah, I am liking this more and more.
[16:18] <jam> radix: then again, if you are doing something like PQM, you'll never get a chance to review it how it is merged
[16:18] <jam> because there may be 3 patches that make there way in first
[16:18] <Peng> jam: ? was at Stavros suddenly parting.
[16:19] <Peng> Sorry.
[16:19] <Stavros> I currently have a bugfix sitting for months because I haven't finished the feature I was working on :(
[16:19] <jam> Stavros: feature branches FTW
[16:19] <radix> heh
[16:19] <Stavros> jam: You branch your code per-feature?
[16:19] <jam> Stavros: http://bzr.arbash-meinel.com/branches/bzr/
[16:19] <jam> About 279 branches last I counted
[16:20] <jam> per feature, per bugfix, per ....
[16:20] <Stavros> Oh, isn't that like tagging in SVN?
[16:20] <Stavros> Nice, I was wondering how to do that...
[16:20] <radix> no, it's like branching in SVN :)
[16:20] <Stavros> Oh, so you merge them back when done...
[16:20] <jam> radix: except it remembers when you only merge part of a feature
[16:20] <jam> so that when it gets more work on it
[16:20] <radix> but it's a workflow thing, not really determined by the VC.... and as jam points out, the VC can help
[16:20] <jam> you can simply merge again
[16:21] <Stavros> Yes, that's true.
[16:21] <radix> but the basic idea is that ANY distinct development you want to do, you should start a branch for it
[16:21] <Stavros> I love the fact that you don't need a server, you can just use SSH.
[16:21] <Stavros> radix: I usually don't bother, if I'm the only one working on it...
[16:21] <jam> Stavros: yeah, having used Bazaar, trying to "svn/cvs init" a new project is horribly hard
[16:21] <jam> radix, Stavros: there is also a nice discussion here: http://www.venge.net/mtn-wiki/DaggyFixes
[16:22] <jam> But I don't know many people who go to the extra effort
[16:22] <jam> DaggyFixes are very nice conceptually
[16:22] <radix> Stavros: yeah, generally I don't either, at the very beginning of a project. but even if I remain solo, I generally eventually switch to branch-based development once the project gets semi-mature
[16:22] <jam> I actually tried doing branch-based devel in CVS back in the day, because it seemed like the "right thing"
[16:22] <jam> But man was it painful
[16:23] <jam> So I just ended up with release-level branches
[16:23] <jam> 0.6, 0.7, etc
[16:23] <Stavros> radix: I don't see why, since I'll only be working on one feature at a time usually...
[16:23] <Stavros> Is there a way to switch from SVN to bzr?
[16:23] <radix> jam: hell yeah. I remember that.
[16:23] <Stavros> Easily? :(
[16:23] <radix> Stavros: yep.
[16:23] <jam> Stavros: bzr-svn
[16:24] <jam> "bzr pull svn://host/trunk"
[16:24] <radix> Stavros: there's a whole-repo conversion tool, as well as a thing that allows you to use an SVN repo as if it were a bzr branch.
[16:24] <Stavros> Ah, great. I tried a bzr2svn script but it didn't work
[16:24] <radix> jam's describing that last thing.
[16:24] <jam> I think bzr-svn also provides
[16:24] <jam> bzr svn-import
[16:24] <radix> oh, neat.
[16:24] <jam> Which does the whole repo import
[16:24]  * Peng deletes 100 MB of testbzr-*.log files.
[16:24] <Peng> :\
[16:24] <radix> i guess bzr-svn is winning these days.
[16:24] <Stavros> Well, I have a repo that has my projects somewhere and I want to make each SVN branch a bzr branch.
[16:24] <Stavros> So, bzr-svn would be what I need?
[16:24] <jam> Last I knew, I thought svn2bzr was adapting the same conversion logic
[16:25] <jam> so they would be compatible
[16:25] <Stavros> jam: It's not working, though :/
[16:25] <jam> https://launchpad.net/bzr-svn
[16:25] <radix> Stavros: yeah, bzr-svn. not svn2bzr; that's a different thing.
[16:25] <Stavros> radix: Great, thanks, I'll do it now.
[16:25] <Stavros> Oh hmm, I need to wait for the new laptop. Damn, foiled.
[16:26]  * radix is waiting for his new laptop as well. It's taking lenovo a *month* to get it out the door!
[16:26] <Stavros> It's taking Apple two weeks :/
[16:26] <Stavros> By the way, is there a way to update the working copy immediately when pushing, so I can have the production server change to the new code immediately when pushed?
[16:27] <jam> Stavros: https://launchpad.net/bzr-push-and-update
[16:27] <jam> Another plugin which does "ssh server bzr update" for you
[16:27] <jam> *if* there is a working tree there
[16:27] <Stavros> I don't suppose it can run commands too, can it? :/
[16:27] <Stavros> apache restart, in particular
[16:27] <jam> Stavros: it wouldn't be hard to add into it
[16:27] <jam> but not at the moment :)
[16:27] <Stavros> Ah, there's something for me to work on, then :P
[16:29] <jam> Stavros: patches welcome :) It is pretty trivial to do so, except you need to somehow do the configuration to know what commands to run, etc.
[16:29] <jam> I would probably go with reading the targets Branch.get_config() (which points at .bzr/branch/branch.conf) and having a "post_push_and_update_commands = XXX" or something to that effect
[16:29] <Stavros> jam: True... It wouldn't be hard to have it read a shell script to perform on update...
[16:30] <Stavros> Hmm...
[16:30] <radix> jam: looks like you need to update the launchpad description
[16:30] <vila> Peng: bug #123363 ?
[16:30] <ubotu> Launchpad bug 123363 in bzr "selftest pollutes /tmp" [Medium,Confirmed] https://launchpad.net/bugs/123363
[16:30] <radix> jam: since you made it a push post-hook and don't require "bzr push-and-update" any more
[16:31] <Stavros> Man, my sister isn't going to be pleased with all the development stuff I've loaded her laptop with...
[16:31] <jam> probably
[16:31] <vila> jam: you know Stavros sister ???
[16:32] <Stavros> How do you know her?!?! Damn you.
[16:32] <radix> blasted "context" stuff :)
[16:32] <jam> radix: can't I just hire someone to take care of all the doc stuff? I'm too busy hacking :)
[16:33] <radix> hehe. I'd offer my services, but I'm not sure my employer would be happy with me moonlighting for another employee. :-)
[16:35] <jam> vila: is that still happening?
[16:35] <jam> (I don't really run the whole test suite often)
[16:35] <jam> I always blamed bzrtools, just to make myself feel better
[16:36] <jam> The ones I see right now seem partially if I do "^C" while it is running.
[16:37] <vila> jam: yes still happening, I had to reboot my test PC today so only for today with just a few full selftest : 1688 testbzr.*.log and a couple of tmp.* dirs
[16:37] <mw> woohoo, 1.0!
[16:37] <jam> hm... I only had 88 and most of the ones I actually looked at were KeyboardInterrupt ones
[16:37] <Stavros> How do I use bzr-svn? Do I just pull my branch?
[16:37] <jam> Stavros: generally you would do some form of:
[16:37] <jam> bzr init target
[16:38] <jam> cd target
[16:38] <jam> bzr pull http://svn.source/branch
[16:38] <jam> I'm not sure if "bzr branch http://svn.source/branch" works
[16:38] <luks> which wouldn't work :)
[16:38] <luks> branch works
[16:38] <jam> Simply because Bazaar generally preserves source formats
[16:38] <luks> or bzr init --format=rich-root
[16:38] <jam> luks: ah, because you need "bzr init --rich-root" ?
[16:38] <jam> We need to get that the default soon
[16:39] <luks> why it isn't the default pack format anyway?
[16:39] <jam> well, rich-root-pack at least
[16:39] <mgedmin> congratulations for the 1.0!
[16:39] <jam> luks: race conditions (rich root pack came out ~ the same time pack-0.92 became default)
[16:39] <jam> Also, upgrade is slower
[16:39] <jam> knit => pack 0.92 is just shuffling some bits around
[16:39] <jam> => rich-root requires regenerating the inventory files
[16:39] <jam> aka slow
[16:40] <Stavros> I love not having to have everything under one repo, like in SVN.
[16:40] <mgedmin> you may want to remove this sentence from the front page of http://bazaar-vcs.org/: "Following a sprint in London in May 2007 which brought together many of our core contributors, we now have a plan for 1.0."
[16:40] <jam> Oh, and I think Robert pushed for packs, Aaron wrote rich-root :)
[16:41] <fullermd> The sneaky solution is to get the inventory rewrite pushed in; then the upgrade has to rewrite 'em anyway, so you can push to rich-root behind everyone's back at the same time.
[16:41] <jam> mgedmin: thanks
[16:41] <jam> done
[16:41] <Stavros> Oh, bzr-svn can't handle auth? :(
[16:42] <jelmer> Stavros: It can, but can't ask for credentials
[16:42] <jelmer> Stavros: it will use the credentials Subversion has cached
[16:42] <jam> jelmer: why is that?
[16:42] <jam> out of curiosity
[16:42] <Stavros> Oh, I need subversion too? :P
[16:43] <mgedmin> hm, the ubuntu gutsy repo still only has 1.0~rc1-3bazaar1, I'll wait before upgrading
[16:43] <jam> mgedmin: yeah, I think poolie is on the packaging while lifeless is away
[16:43] <jelmer> jam: up until a few weeks ago, it was impossible to register credentials providers in the subversion client libs
[16:43] <Stavros> I'll do it on the server itself and just pull from that, then.
[16:43] <jam> jelmer: ah, so just not exposed at the library level
[16:43] <jam> that's crummy
[16:44] <jelmer> jam: Yep. It is now, and I'm working on support for AuthenticationConfig. Hopefully that'll be in 0.4.6
[16:44] <jam> having poked through gits codebase again, I'm reminded why writing a library first is better
[16:44] <jam> and then command code that calls into that
[16:44] <jelmer> jam: It's actually exposed at the library level, the python bindings were broken though
[16:44] <jam> There is a whole lot of global state that you have to figure out
[16:44] <fullermd> You don't need a library.  You just connect up commands through a shell script...
[16:45] <jam> fullermd: yeah, and then *each* git process gets to parse all of the index files again
[16:45] <fullermd> Yeah, but that doesn't matter, 'cuz git is so fast each process finishes before the previous one.
[16:46] <jam> Well, in *my* testing, creating a git branch by doing "git init; git add; git commit" was *vastly* slower than doing git fast-import
[16:46] <jam> Like <1s versus 20s
[16:47] <jam> And git even has their fancy index to make everything faster
[16:48]  * jam => stops talking to all the nice people and tries to actually get some work done
[16:48] <radix> jam: oh, thanks for pointing out that DaggyFixes wiki link. We do that in Landscape. But what I'm happy about is that they mentioned monotone's "disapprove", which I didn't know about. I filed bug #152008 a while ago and it looks like "disapprove" is the kind of operation I need.
[16:48] <ubotu> Launchpad bug 152008 in bzr "Ability to unmerge or revert a merge sensibly" [Wishlist,Triaged] https://launchpad.net/bugs/152008
[16:48] <Stavros> That's odd, there's an ubuntu "bazaar" package that isn't bzr...
[16:50] <jam> Stavros: Baz-1.x
[16:50] <jam> It was an initial attempt at a better version control
[16:50] <jam> based on Arch
[16:50] <jam> which ended up having fundamental issues
[16:50] <jam> So 'bzr' was bord
[16:50] <jam> born
[16:50] <jam> damn, I said I was leaving :)
[16:50] <Stavros> Ah, I see... I was wondering why it was at 1.4.2...
[16:50] <Stavros> Yes, you did :P
[16:51] <luks> people always say that on irc :)
[16:51] <Peng> jam: So, you organize http://bzr.arbash-meinel.com/branches/bzr/ by bzr version?
[16:51] <jam> well, i blame radix  he mentioned my name
[16:51] <jam> Peng: generally
[16:51] <jam> When you have 100 branches
[16:51] <radix> sorry :)
[16:51] <jam> simply putting them in a branches/ dir isn't sufficient
[16:51] <jam> Peng: it is sorted by the approximate revision I expect them to land in
[16:51] <jam> s/revision/release
[16:52] <jam> I could have just done it by month, or something
[16:52] <Peng> All of my branches are just simple typo fix sorta things (and one trivial bug), but I push them because thanks to my locations.conf, the URL is automatically included in bundles.
[16:52] <Stavros> Any idea why bzr-svn isn't authenticating? svn co worked fine...
[16:52] <jelmer> Stavros: You can try prefixing the URL with svn+
[16:52] <Peng> I'm an organization nut, so I've been worrying about how to organize it.
[16:52] <Peng> (Well, I'm not OCD in general, just with HTTP.)
[16:52] <jam> Peng: date based works fairly well for me
[16:52] <Stavros> jelmer: unsupported protocol, svn+http :/
[16:52] <jam> Peng: but I wrote a doc on it: http://bazaar-vcs.org/SharedRepositoryLayouts
[16:53] <jam> Stavros: do you have bzr-svn installed correctly?
[16:53] <jelmer> Stavros: are you sure you have bzr-svn installed?
[16:53] <jam> cd ~/.bazaar/plugins
[16:53] <jam> bzr checkout lp:bzr-svn svn
[16:53] <jam> It should be in ~/.bazaar/plugins/svn
[16:53] <Stavros> jelmer: Uh. It would have been better if I hadn't forgotten to do that :/
[16:53] <Stavros> Sorry.
[16:53] <jam> unless you are installing from debs
[16:53] <Peng> I decided to create a 'trivial/' directory and put all those things there, and leave the top level for long-lived branches, supposing I ever create one.
[16:54] <Stavros> Same thing still, "Not a branch"
[16:54] <jam> Peng: for the real OCD, you can always nuke them after they have been merged
[16:54] <Stavros> I'll just point it to the actual SVN dir.
[16:54] <jam> I think there is a plugin for that
[16:55] <Peng> I've never left a 404.
[16:55] <Stavros> Still not a branch, that's odd...
[16:55] <jam> radix: that was the "I want to pretend I didn't merge" so that it backs out the change *and* removes it from the ancestry so a future merge will pull the whole thing in?
[16:56] <Peng> I'm OCD about good organization and no name clashes, and never leaving 404s, not tidyness.
[16:56] <Peng> I have thought of that though.
[16:58] <Stavros> Any idea what "Not a branch" could mean?
[16:58] <jelmer> Stavros: Does "bzr plugins" list the svn plugin?
[16:58] <Stavros> Yes.
[16:59] <Stavros> I'm pointing it to a directory in the trunk.
[17:00] <Peng> The other thing is that Apache directory listings don't give the status of the branch (experimental, merged, whatever) like Launchpad does.
[17:00] <radix> jam: yes. I added a comment to the bug.
[17:01] <jam> I replied
[17:01] <jam> I think disapprove(A) is just merge(A..A') commit
[17:01] <jam> But not having used it extensively...
[17:01] <jam> (or at all :)
[17:05] <Stavros> Apparently bzr-svn can only be pointed at trunk/? Can't I make a bzr repo out of a SVN subdirectory?
[17:05] <jam> Stavros: bzr help branch-layouts
[17:05] <jam> or something like that
[17:05] <jam> You have to do some work if you want projects underneath the main trunk
[17:06] <jam> bzr-svn makes sure that if 2 people checkout the same source, they can interoperate
[17:06] <jam> so they have to agree on how the projects are laid out
[17:07] <Stavros> Oh... I only need it for one-time migration, though...
[17:08] <Stavros> The only commands svn has are svn-import and svn-upgrade.
[17:08] <jam> Stavros: it is a help topic
[17:08] <jam> try "bzr help topics"
[17:09] <Stavros> Nothing there either :/
[17:09] <Stavros> formats?
[17:09] <Stavros> Nope.
[17:10] <jam> bzr help svn-branching-scheme
[17:11] <jam> Is supposed to be the help topic
[17:11] <jam> according to luks
[17:11] <jam> from yesterday
[17:11] <Stavros> Nothing there :/
[17:11] <luks> not really a help topic, but you can set your own branching scheme there
[17:12] <luks> but you can also with the command line options in svn-import
[17:12] <jam> Stavros: http://rafb.net/p/nCHdmV87.html
[17:12] <luks> s/also/also play/
[17:12] <jam> But what version bzr-svn do you have installed?
[17:12] <Stavros> jam: The one from the ubuntu repos.
[17:13] <Stavros> Probably oldish?
[17:13] <jam> Stavros: do you know the number?
[17:13] <jam> you need >0.4 to get branching schemes
[17:13] <jam> 0.3 didn't support it
[17:13] <Stavros> Let me check.
[17:14] <Stavros> 0.3.2, aha.
[17:14] <jam> jelmer: do you support "trunk/project/*" out-of-the-box
[17:14] <jam> Or does that require "ListBranchingScheme" ?
[17:15] <jam> Stavros: peeking at the code it looks like the dev code supports it out-of-the-box
[17:16] <Stavros> jam: It says it can't find plugin "svn" now...
[17:16] <Stavros> Unable to load, to be exact
[17:16] <jam> Stavros: cannot find, or cannot load?
[17:16] <jam> vi ~/.bzr.log
[17:16] <jam> will give more info about why it is failing
[17:16] <jam> Probably needs a newer bzr... :(
[17:16] <Stavros> No log there, let me get the newest bzr.
[17:17] <jelmer> re
[17:18] <Stavros> grr, repository incompativle
[17:19] <jelmer> Stavros: What sort of command are you running?
[17:19] <Stavros> pull
[17:19] <jelmer> you'll have to upgrade the branch you're pulling into
[17:19] <Stavros> Hang on, I saw this somewhere on the bzr-svn FAQ.
[17:19] <jelmer> bzr upgrade --rich-root
[17:20] <Stavros> Ah, thanks.
[17:20] <jelmer> or if you simply want to make a clone of the branch that exists in svn, use "bzr branch <svn-url> <local-dir>"
[17:21] <Stavros> Isn't it odd that it takes minutes to convert an empty repo?
[17:21] <mkanat> Congrats on 1.0, everybody. :-)
[17:21] <Stavros> Or maybe it's checking out as well.
[17:21] <jelmer> Stavros: during "bzr upgrade" you mean?
[17:21] <Stavros> jelmer: Yes.
[17:22] <Stavros> Yay, the pull seems to have worked.
[17:24] <jelmer> jam: The sooner we can get rid of branching schemes, the better..
[17:24] <jam> jelmer: except I think SVN's model is broken, so trying to enforce some sort of logic on it...
[17:26] <jelmer> jam: Branching schemes will still be required in any case but it should be possible to hide them from the user much more.
[17:29] <Stavros> How can I check which revision I'm at?
[17:29] <jam> bzr log -r -1 ?
[17:29] <jam> Or just bzr revno
[17:29] <Stavros> Ah, thanks.
[17:30] <jam> but revno is branch specific
[17:30] <Stavros> The command line is a bit tedious for viewing changes, I must admit...
[17:30] <jam> 2 branches can have the same simple revision number (aka revision 10)
[17:30] <Stavros> Oh, hmm.
[17:30] <jam> Stavros: you might try installing bzr-gtk
[17:30] <Stavros> Windows atm :/
[17:30] <jam> and then you have "bzr viz"
[17:31] <jam> Stavros: still works ther
[17:31] <jam> but I guess the gtk dependencies are a bit harder to get
[17:31] <Stavros> Aha, great, I'll do that then.
[17:31] <Stavros> Hmm, true...
[17:31] <jam> There is also a TortoiseBzr that is part of bzr-gtk
[17:31] <Daviey> jam: embarrassingly i found the problem...  The word that was causing a problem got filtered via procmail on the incomming email :(  silly me
[17:31] <jam> but I don't think it is nearly as polished as TortoiseSVN
[17:31] <jam> Daviey: so it was generating them, but you weren't getting them ... weird
[17:31] <Stavros> Well, TortoiseSVN has had years of development...
[17:32] <Daviey> jam: yeah, my fault entirely :(
[17:32] <jam> Stavros: well, at the moment, I think it still needs a caching server
[17:32] <luks> Stavros, if you want something quickly installed - http://bazaar-vcs.org/QBzr
[17:32] <jam> so that it doesn't slow down all of for basic Exploring
[17:33] <Stavros> jam: That's true, that does take ages sometimes.
[17:33] <Stavros> luks: Oh, nice, thanks.
[17:33] <jam> "all of your"
[17:33] <jam> luks: so do you bundle the QT libs?
[17:33] <luks> yes
[17:34] <jam> someone needs to get "apt" working on Windows :)
[17:34] <luks> that would be impossible
[17:34] <Stavros> Well, you'd have to make a different tool for windows...
[17:34] <luks> programs on windows usually depends on specific versions of libraries
[17:35] <jam> yeah, it just seems silly to have 10 versions of similar DLLs
[17:35] <jam> considering that was the *point* of DLLs
[17:35] <luks> even MS decided that all apps build with MSVC should ship their own stdc library
[17:35] <Stavros> luks: That is a nice utility.
[17:36] <Stavros> Wow, I can even see the changes by clicking, awesome.
[17:36] <luks> heh
[17:37] <Stavros> By the way, I am reading the daggyfixes thing, how do you do that? Branch from the change that introduced the bug, fix it and push it back to the repo?
[17:37] <jam> Stavros: something like that
[17:38] <jam> "bzr branch -r XX fix_bug_foo
[17:38] <Stavros> Does it merge all the new changes correctly?
[17:38] <jam> Stavros: the "push" won't but doing
[17:38] <jam> cd trunk
[17:38] <jam> bzr merge ../bugfix
[17:38] <jam> will do just fine
[17:38] <jam> 'bzr push' won't let you
[17:38] <jam> because they are diverged branches
[17:39] <jam> Stavros:  you might look at: http://doc.bazaar-vcs.org/bzr.dev/en/tutorials/centralized_workflow.html
[17:39] <Stavros> Hmm, I find it a bit odd that it can correctly merge two very different files... How do you know it won't merge the changes from the old file back?
[17:39] <jam> It might be a decent migration path coming from SVN
[17:40] <Stavros> I've sort of read that, it's my personal repo so it's not that huge a deal.
[17:40] <jam> Stavros: generally we know what set of changes are present, and use a 3-way merge logic
[17:40] <Stavros> Just trying to learn stuff atm.
[17:40] <Stavros> Aha.
[18:05] <Stavros> Hmm, I was wondering why this room had gone silent...
[18:15] <jam> I was wondering what you "aha" moment was :)
[18:15] <Peng> Stavros: You didn't miss anything. Just some joins and parts.
[18:16] <Stavros> Ah, good then.
[18:16] <Stavros> Wireless isn't that reliable, apparently.
[18:19] <mrZeby> hello all... i have installed qbzr but when i launch it a have the message "unable to load plugin qbzr..." when i start bzr... somebady can help me, please ?
[18:20] <Stavros> mrZeby: Which OS?
[18:20] <mrZeby> vista :-).. sorry
[18:20] <Stavros> That's odd, I just installed it and it worked fine... Which installer did you use?
[18:21] <mrZeby> but i had the same problem last time i try to use on xp
[18:21] <mrZeby> i use python based installer
[18:21] <Stavros> Try the other one, with everything included.
[18:21] <mrZeby> i had allready installed python for other program
[18:21] <mrZeby> python 2.5
[18:22] <Stavros> Doesn't matter, it should work anyway.
[18:22] <Stavros> It doesn't actually have python in it.
[18:22] <mrZeby> i had install bzr with python installer too
[18:23] <mrZeby> ok i try the windows installer
[18:23] <mrZeby> but perhaps i can install other thinks.. like pyqt ... ?
[18:24] <Stavros> mrZeby: No, the installer has everything.
[18:24] <jam> You can check C:\Documents and Settings\<username>\.bzr.log
[18:24] <jam> which should tell you why qbzr isn't loading
[18:24] <jam> which could be something like pyqt not being installed
[18:24] <jam> The standalone installer should package everything
[18:24] <mrZeby> ok i take a look
[18:24] <jam> but you may want to re-use your python install
[18:25] <jam> mrZeby: You can also check "bzr --version"
[18:25] <jam> It should have a line for:
[18:25] <jam> Bazaar log file: /Users/jameinel/.bzr.log
[18:29] <zero-9376> is it possible to modify the email address for a previous revision? for some reason the email reverted to username@host rather than using the config file in my home directory
[18:30] <mrZeby> ok i found bzr.log...
[18:31] <mrZeby> ok ok "ImportError: No module named PyQt4
[18:31] <Stavros> mrZeby: Yeah, just use the bundle.
[18:32] <mrZeby> the complete bundle would re install other python directory ?
[18:32] <Stavros> No, it doesn't install stuff anywhere else.
[18:34] <mrZeby> do you think i must reinstall bzr with windows installer to ?
[18:34] <mrZeby> too
[18:36] <zero-9376> is there any way to do this?
[18:37] <jam> zero-9376: I do it like that. :)
[18:38] <zero-9376> sorry i don't understand
[18:39] <jam> You said "this" without saying what you wanted
[18:39] <jam> So I said "that" without telling you how to do it
[18:39] <zero-9376> (04:29:10) zero-9376: is it possible to modify the email address for a previous revision? for some reason the email reverted to username@host rather than using the config file in my home directory
[18:39] <jam> zero-9376: for the previous commit, you can "bzr uncommit; bzr commit" again
[18:39] <jam> Otherwise, no
[18:39] <Stavros> You can uncommit stuff?
[18:40] <jam> Stavros: yes
[18:40] <Stavros> Wow, what does it do? Make it as if you never committed?
[18:40] <jam> Branches are just pointers into a revision graph
[18:40] <jam> so you are free to move them around if you need to
[18:40] <jam> Stavros: it leaves the commit available in the repository
[18:40] <jam> but the branch itself doesn't reference it anymore
[18:40] <Stavros> Ah
[18:41] <jam> And when someone branches from you, they won't get that revision, etc.
[18:41] <Stavros> I must research more.
[18:41] <Stavros> But first, Futurama!
[18:41] <woei> and when someone branches from you before you uncommitted and then tries to push/merge with you ?
[18:41] <Stavros> Later all, thanks for the help!
[18:41] <jam> woei: If you have a new commit, it will tell them the branches have diverged
[18:41] <jam> woei: if you just did uncommit
[18:41] <jam> it won't do anything
[18:42] <jam> because the source is an ancestor of the target
[18:42] <jam> they can "pull --overwrite" to switch to your new commit
[18:42] <woei> I see
[18:42] <jam> or they can "bzr merge" if they really wanted that comimt
[18:42] <jam> commit
[18:43] <jam> (pull --overwrite should also change your local branch to move backwards)
[18:43] <woei> hmm, but what if someone branched from you, you uncommitted the version they branched from, you work some on your branch, the other person(s) work some on their branch. It's just merging as usual ?
[18:44] <woei> seems logical, if you take the 'branch is just a pointer in an entire revision graph' angle
[18:44] <jam> woei: right
[18:44] <jam> uncommit doesn't record that there was a change
[18:44] <jam> if you want to reject a patch you need to do
[18:44] <jam> bzr revert -r -2; bzr commit -m "revert that last change, what was I thinking"
[18:45] <jam> Or if it is further back you can do
[18:45] <jam> bzr merge -r 10..9; bzr commit -m "revert the changes introduced in revision 10, WWIT?"
[18:45] <woei> excellent
[18:46] <woei> thanks for the pointers
[18:46] <jam> always happy to help
[18:46] <bos> hey, guys.  there's been a bit of discussion on reddit about the bzr wiki pages regarding git and hg.  have you seen it?
[18:47] <jam> bos: not specifically, any links?
[18:48] <bos> http://programming.reddit.com/info/62z0v/comments/
[18:48] <bos> i read the wiki pages.  they're very disappointing.
[18:49] <bos> they have such an overt and obvious bias to them that it's hard to take anything they say seriously.
[18:49] <bos> which seems to be the consensus on reddit, too.
[18:50] <mrZeby> thanks a lot for your help mr Stavros :-)
[18:50] <bos> obviously, you should be advocating for bzr based on its strengths, but it doesn't do any favours to provide biased and distorted comments about the competition.
[18:51] <bos> that is to say, it doesn't do bzr any favours.
[18:52] <jam> bos: it is also a bit hard to be perfectly balanced when writing from one side. but I would certainly be interested in reading a logical counterpart to it
[18:52] <jam> I saw a bit of wiki stuff on selenic, but that seemed full of a lot of anger more than simple reasoning
[18:53] <mrZeby> a question more can i ? the windows installer wuold install qbzr on directory C:\Users\mrZeby\AppData\Roaming\bazaar\2.0\plugins\qbzr
[18:53] <jam> It certainly wasn't the point to strictly bash on other systems
[18:53] <bos> jam: i don't know about the selenic stuff, i'm afraid.  haven't read it.
[18:53] <mrZeby> can i install it on c:\program files\Qbzr ?
[18:53] <jam> We were hoping for mostly a comparison of where the projects have chosen different paths
[18:54] <jam> But it can take a bit of balancing and editing to get there
[18:54] <jam> I also haven't spent much time doing more than skimming them
[18:56] <bos> yeah.
[18:56] <bos> just wanted to bring it to your attention.
[18:56] <jam> bos: care to flesh out some of the Hg points? (Preferably in an email)
[18:56] <jam> I seem to recall you were pretty good with writing :)
[18:57] <bos> jam: honestly, i probably don't have time.  i'm, shall we say, a bit overcommitted.
[18:57] <jam> bos: np
[18:57] <jam> We all get that way
[18:58] <bos> nice talking, as always. cheers!
[18:58] <jam> I just think of you as a well spoken person who has good opinions
[18:58] <jam> Rather than just a random fanatic
[18:58] <jam> later
[18:58] <bos> :-)
[19:00] <mrZeby> how to launch qbzr ?
[19:01] <mrZeby> i have installed bzr and qbzr but i don't how to launch qbzr
[19:02] <jam> mrZeby: generally you do something like:
[19:02] <jam> bzr qannotate FILENAME
[19:02] <jam> bzr glog
[19:02] <jam> sorry
[19:02] <jam> bzr qlog
[19:02] <jam> etc
[19:02] <jam> I don't know if there is an app you can just run
[19:02] <jam> luks: ^^ ?
[19:04] <mrZeby> jam : before i have install bzr and qbzr and when i launch bzr it automaticly try to launch qbzr but said that qbzr can be launch because of missing pyqt4
[19:05] <mrZeby> jam i have install python installer
[19:05] <jam> mrZeby: The best I can say is that you need to have the new bzr in your path
[19:05] <jam> But *I* have never used it.
[19:05] <jam> so I can't help much more than giving general pointers
[19:05] <mrZeby> jam after ( now ) i use windows installer and... nothing about qbzr wjen launching bzr
[19:06] <radix> mrZeby: ok, then does "bzr qlog" do something interesting?
[19:07] <mrZeby> jam bzr error unknow command
[19:08] <jam> mrZeby: Are you using the "Windows python installer" or the "Windows standalone installer" ?
[19:08] <jam> And if you are using "Windows standalone installer"
[19:08] <jam> did you install Bazaar from the "Windows standalone installer"
[19:08] <mrZeby> first i have use python installer but know i have used windows installer
[19:09] <mrZeby> i will retry with python installer and installing pyqt4 manually
[19:09] <jam> You probably want to use: https://edge.launchpad.net/bzr/1.0/1.0/+download/bzr-setup-1.0.0.exe
[19:09] <jam> coupled with https://launchpad.net/qbzr/trunk/0.8.0/+download/qbzr-setup-0.8.0.exe
[19:09] <radix> s/edge.//
[19:10] <mrZeby> i did it like this now...
[19:11] <mrZeby> i continu trying the install...
[19:12] <mrZeby> radiix thanks for your help... see you later perhaps :-)
[19:12] <mrZeby> jam thanks for your help... see you later perhaps :-)
[19:12] <jam> k
[19:12] <jam> later
[19:12] <mrZeby> radix thanks for your help... see you later perhaps :-)
[19:13] <radix> :-)
[20:59] <Solarion> how do I create an svn archive from bzr?
[21:00] <Solarion> (upstream uses svn; I use bzr)
[21:00] <radix> Solarion: I don't know if that's possible. why do you want to do it? does upstream just want to be able to merge your changes?
[21:01] <Solarion> radix: upstream (Professor ;) wants me to create new archive with this code
[21:01] <Solarion> eh, I can just do it with svn and push up the stuff
[21:01] <radix> Solarion: so, bzr-svn supports committing back to SVN
[21:01] <Solarion> radix: is what I've been using to stay sane.  ;)
[21:02] <Solarion> but we're breaking new ground, and he wanted me to make a new repo
[21:02] <radix> ah. I see. yeah, I don't know if there's a way to create an SVN repository straight up out of a bzr-svn branch...
[21:02] <radix> maybe you can push it to an empty SVN repository?
[21:02] <luks> you should be able to push to an empty svn reporitory
[21:02] <radix> cool :)
[21:03] <Solarion> I'm being told I need to merge then push
[21:03] <Solarion> "these brnaches have diverged"
[21:04] <luks> hm, I think I remember some bzr-svn announce mail where jelmer said he created a svn repo for bzr.dev
[21:06] <luks> http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/29013
[21:08]  * Solarion scratches his head.. how do you merge with no common ancestor, again?
[21:08] <Solarion> bzr merge -r 1.. <src>
[21:09] <Solarion> or not.  It didn't do anything.  :(
[21:11] <Solarion> bzr merge -r ..2 <src>
[21:12] <Solarion> thanks
[21:13] <Solarion> bzr-svn keeps me sane.  :)
[21:21] <jelmer> Solarion: hi
[21:21] <jelmer> Solarion: did you manage to push into svn?
[21:24] <Solarion> jelmer: yes, after a while
[21:24] <Solarion> I had to use svnadmin to create the branch, tho.
[21:24] <jelmer> you should also be able to use "bzr init-repo --format=subversion"
[21:25] <Solarion> jelmer: wouldn't that make a local svn repo?
[21:25] <jelmer> yes, it would
[21:25] <Solarion> I'm wanting a local bzr, remote svn repo.  :)
[21:25] <jelmer> creating a branch in a remote svn repo should be possible using svn-push
[21:25] <Solarion> aah
[21:26] <Solarion> then you branch it with bzr?
[21:26] <jelmer> you can push an existing bazaar branch into subversion that way
[21:26] <jelmer> e.g.:
[21:26] <jelmer> bzr branch http://bazaar-vcs.org/bzr/bzr.dev bzr.dev
[21:27] <jelmer> bzr init-repo --format=subversion svn.bzr
[21:27] <jelmer> cd bzr.dev && bzr svn-push ../svn.bzr/trunk
[21:27] <jelmer> or even "bzr svn-push svn+ssh://example.com/existing-svn/repo/trunk"
[21:27] <jelmer> (where the trunk didn't exist yet)
[21:29] <Solarion> maybe something's outta whack, 'cause I get connection refused.
[21:30] <Solarion> ah well, it works now.  that's all that matters at the moment.
[21:35] <statik> hi, I'm trying to set up bzr on a remote web host, where I can only install in my home directory
[21:35] <statik> I am able to run bzr just fine when I am logged into the machine, but trying to push to a bzr+ssh path on that system gives me an error about not being able to find the bzrlib
[21:36] <statik> I'm sure that there is some trick that causes pythonpath to not be set when I am executing a command remotely over ssh
[21:36] <statik> anyone with better knowledge of ssh have a suggestion?
[21:37] <dato> well, it's not a matter of python path, because the directory of the executable will be search for bzrlib
[21:37] <dato> so probably is the executable itself that is not being found
[21:37] <dato> there's an env variable for that, iirc
[21:37] <statik> yes, I've tried setting bzr_remote_path
[21:37] <statik> but I think the executable is being found
[21:37] <dato> uhm
[21:38] <statik> 'ssh webserver "which bzr"' shows me the bzr command is found
[21:39] <dato> oh
[21:39] <statik> ssh webserver python -c "import bzrlib" shows me the same error I get from running ssh webserver bzr --version
[21:39] <dato> so in your instalation, is the executable and the bzrlib in different directories?
[21:39] <statik> about no module named bzrlib
[21:40] <statik> yes, I did python setup.py install --home ~
[21:40] <jelmer> statik: what about python -c "import sys; print sys.path" ?
[21:40] <dato> statik:  I'd recommend you move back the executable to the same directory as bzrlib, and make a symlink from that location to ~/bin or so
[21:41]  * dato always run from source in $remotehostswithoutroot
[21:41] <statik> basically the problem is that my .profile is executed and sets $PYTHONPATH correctly when I am logged in interactively
[21:41] <statik> but it is not set when I invoke a remote command over ssh
[21:44] <statik> dato: running with BZR_REMOTE_PATH set to the location of bzr in the extracted source tree rather than the installed location worked great! thanks
[21:44] <statik> this is great, I prefer not to have to run setup.py anyway
[21:44] <dato> you're welcome
[21:46] <statik> is there a way for me to tell bzr to update the working tree on the remote server when I push? I'd like to use this to rollout updates to a web server, so I want the working tree updated when I push
[21:46] <statik> I thought bzr+ssh would allow that, while sftp would not
[21:46] <dato> install http://launchpad.net/bzr-push-and-update
[21:46] <dato> voilà
[21:47] <dato> oh, but create a tree in the remote host first, with `bzr checkout .`
[21:47] <statik> ah, great. thanks again!
[21:47] <jam> dato: getting all the credit :)
[21:48] <jam> is it voilà or voilá ?
[21:48] <statik> jam: btw, CONGRATULATIONS! on 1.0
[21:48] <jam> statik: thanks
[21:48] <glyph> jam: hey, about push-and-update; I haven't had the opportunity to try it yet, but will it work on Windows?
[21:48] <jam> glyph: as long as you have 'ssh' available
[21:49] <glyph> jam: I don't :( I have plink
[21:49] <glyph> jam: is there an easy way to make it consider the BZR_SSH variable?
[21:50] <statik> heh, I wondered why I had not heard of this plugin before. jam you've been busy
[21:52] <dato> jam, voilà (http://fr.wiktionary.org/wiki/voilà)
[21:53] <dato> jam: I'm giving you this tiny french lesson in exchange for the credit :-PP
[21:54] <dato> heh
[21:54] <dato> Top contributors
[21:54] <dato>  bwinton    15 points
[21:54] <dato>    Andrew Cowie    11 points
[21:55] <jam> glyph: we probably could have it hook into the internal SSH code that bazaar hash
[21:55] <jam> has
[21:55] <jam> which  will either spawn ssh, plink, or use paramiko
[21:57] <jam> glyph: it would be something like: vendor = bzrlib.transport.ssh._get_vendor()
[21:57] <jam> connection = vendor.connect_ssh(..., command=[bzr_remote_path, 'update', path)
[21:57] <jam> shouldn't be too hard to do
[21:57] <glyph> jam: #176443 :)
[21:57] <jam> ubotu: bug #176443
[21:57] <ubotu> Launchpad bug 176443 in bzr-push-and-update "push and update does not work if the user does not have ssh, for example on Windows, where they might have plink" [Undecided,New] https://launchpad.net/bugs/176443
[21:58] <glyph> jam: maybe that should have a dependency on a bzr bug though, to make that code not be internal / private
[21:59] <jam> I don't care for this code :)
[21:59] <jam> It is unlikely to change
[21:59] <jam> and if it does
[21:59] <jam> it should be simple to fix
[21:59] <glyph> jam: OK
[22:00] <glyph> jam: Parsing question though; "(I don't care) (for this code)" or "(I don't care for) (this code)"
[22:00] <jam> glyph: first
[22:00] <glyph> OK, works for me
[22:01] <statik> jam: I think bzr-push-and-update should respect the bzr_remote_path config settings. would you agree?
[22:02] <jam> statik: yeah, that would be part of it, too
[22:03] <jam> also, you can set the remote path as part of a config entry
[22:03] <jam> just in case it is different in different places
[22:03] <jam> something like "bzr_remote_path=XXX" in ~/.bazaar/locations.conf
[22:04] <statik> jam: yes, that is what I am doing. I think update_remote_branch() just needs to call config.get_bzr_remote_path()
[22:05] <ubotu> New bug: #176443 in bzr-push-and-update "push and update does not work if the user does not have ssh, for example on Windows, where they might have plink" [High,Triaged] https://launchpad.net/bugs/176443
[22:07] <jam> statik: by the way, patches are welcome :)
[22:07] <statik> jam: just testing it now
[22:15] <statik> jam: I think I need to have the local branch location inside update_remote_branch() in order to query the LocationConfig. does that seem reasonable to you?
[22:17] <jam> statik: what is wrong with just doing:
[22:17] <jam> config = target_branch.get_config()
[22:17] <statik> jam: I like that better, let me try it
[22:17] <jam> remote_bzr = config.get_bzr_remote_path()
[22:18] <jam> or whatever the actual function is
[22:18] <jam> technically, I think it means you can set it in
[22:18] <jam> ssh://host/branch/.bzr/branch/branch.conf
[22:18] <jam> which is a little funny
[22:18] <jam> but it certainly makes the code simpler :)
[22:19] <jam> statik: otherwise, you can just use "target_branch.base"
[22:19] <jam> Which is the URL to that branch
[22:20] <statik> jam: doesn't seem to work. target_branch.base is the path to the remote branch, while I have set bzr_remote_path in locations.conf for my local branch
[22:21] <jam> statik: well, you can set bzr_remote_path for the remote branch :)
[22:21] <jam> but sure
[22:22] <statik> hmm
[22:22] <statik> that might make more sense
[22:22] <statik> I was thinking about it a bit backwards
[22:22] <statik> I'm used to locations.conf referring to local locations
[22:22] <statik> but I might want to set a different remote path for different machines, which is the whole point of having it in locations.conf
[22:23] <jam> statik: it is set based on the remote URL
[22:23] <jam> RemoteSSHTransport
[22:23] <jam> location_config = LocationConfig(self.base)
[22:23] <jam> so you have to set it based on the bzr+ssh://  url
[22:24] <jam> statik: you should be able to do
[22:24] <jam> [bzr+ssh://host]
[22:24] <jam> bzr_remote_path=foo
[22:24] <jam> I'm pretty sure that will catch any branches on that host
[22:24] <statik> beautiful
[22:24] <statik> I'll try that now
[22:29] <statik> jam: it works! do you want this 3-line patch to go to email or the pastebin?
[22:29] <jam> statik: commit it and send me a bundle :)
[22:29] <statik> jam: ok
[22:35] <statik> jam: dumb question, I should use the bzr send command, right? I'm getting an email with a sane subject line but don't see any bundle attached.
[22:36] <Peng> FWIW, I use 'bzr send -o foo.patch' to save the bundle to a file and write my own email.
[22:36] <Peng> I just do that because I haven't wanted to figure out how to configure send, and I like having a copy of the bundle, though. :P
[22:36] <jam> statik: 'bzr send' doesn't work with a single branch
[22:36] <jam> you have to give an upstream
[22:36] <jam> so you need
[22:37] <jam> bzr send lp:bzr-push-and-update
[22:37] <jam> not
[22:37] <statik> it found the upstream, I think I hit this bug https://lists.ubuntu.com/archives/bazaar/2007q3/032053.html
[22:37] <jam> bzr send .
[22:37] <jam> hmm... could be
[22:37] <jam> I always use the "editor" client
[22:37] <jam> since thunderbird on Mac doesn't work properly
[22:37] <jam> Aaron has a workaround for some platforms
[22:37] <jam> but apparently invoking the command line does different things
[22:38] <jam> also, it depends on the thunderbird version
[22:38] <jam> ah, but if xdg-email is spawning thunderbird
[22:38] <jam> then it may not know about the workaraund
[22:38] <jam> workaround
[22:38] <statik> hey, setting mail_client in bazaar.conf fixed it all up
[22:38] <jam> k
[22:40] <jam> statik: you don't need the extra import at the top :)
[22:40] <jam> but otherwise it looks good
[22:40] <statik> oops
[22:41] <jam> the only downside is it won't support BZR_REMOTE_PATH
[22:42] <jam> apparently .get_bzr_remote_bzr_path() doesn't take that into account
[22:42] <statik> oh, I thought when I read the patch from aaron that get_bzr_remote_path() does look at the environment
[22:42] <jam> wait, it does
[22:42] <jam> my grep was confused :)
[22:43] <jam> so, patch merged and committed
[22:44] <statik> and I've now pulled your merge into my local tree. wow this stuff all works great together
[22:45] <statik> on that note, I'm going to spend sometime in the world outside. thanks for all the help, bzr rocks!
[22:47] <jam> statik: have a good weekend