[00:24] <abentley> poolie: I'm up for a call.
[00:28] <poolie> hi
[00:28] <poolie> on skype or something, if you like?
[00:37] <abentley> poolie: http://code.aaronbentley.com/bzr/bzrrepo/288751-pack-deltas
[00:52] <jbalint> how do i handle "Contents conflict", the file has been renamed in the current tree
[00:58] <thumper> how do I change the format of a branch from BranchFormat7 to BranchFormat6?
[01:00] <jbalint> maybe bzr upgrade?
[01:01] <spiv> jbalint: see "bzr help conflicts"
[01:01] <spiv> jbalint: a contents conflict is when bzr sees conflicting changes to a non-text file.
[01:02] <awilkins> Or the addition of a file with the same path
[01:02] <jbalint> hrm, these shouldnt be nontext
[01:02] <awilkins> In two seperate branches
[01:02] <jbalint> one is .h, its the exact files taht are renamted
[01:04] <spiv> awilkins: Hmm, "bzr help conflicts" suggests that would reported differently.
[01:05] <spiv> Note that symlinks and directories count as non-text files...
[01:05] <awilkins> I've never seen a "path" conflict, only content ones
[01:06] <awilkins> And these are for ASCII text files
[01:06] <awilkins> Maybe it's a windows thing?
[01:06] <spiv> Maybe, I wouldn't know.
[01:47] <kingfishr> what is the shortest sequence of commands to give me the equivalent of hg addremove?
[01:51] <spiv> kingfishr: something like "bzr add; bzr commit" IIRC  (commit will automatically remove missing files by default, I think).
[01:52] <kingfishr> oh really?
[01:52] <kingfishr> that's convenient
[01:52] <kingfishr> i wasn't aware of that
[01:53] <spiv> I think --strict will disable that behaviour.  Try it out, it's easy to experiment :
[01:53] <spiv> :)
[02:21] <poolie> jam, are you still around? did you do a patch towards bug 300177, i don't remember
[02:38] <synic> I want to write a clone of gitosis for bzr, I'm just wondering if anyone is already doing this (other than bzr_access)?
[02:39] <james_w> I had heard tell that gitosis may support bzr
[02:39] <james_w> or maybe I'm thinging of something else
[02:40] <synic> hrmm, not in it's current state
[02:42] <spiv> bzr_access is the closest I know if.
[02:42] <spiv> s/if/of/
[02:43] <synic> ok, cool
[05:22] <vila> Gooood morning all
[05:26] <spiv> vila: good morning.
[05:26] <spiv> vila: you seem to be around early today :)
[05:26] <vila> spiv: no, check your clock :)
[05:26] <vila> kidding, I dropped my girlfriend to the airport :)
[05:31] <army> hi ,i have a problem with bzr-svn,
[05:33] <army> bzr 1.9 bzr-svn 0.4.15, check out http://www.prestashop.com/publicsvn ,error
[08:18] <kisielk_home> As a new user to bazaar, I have a few question about repositories. In order to use an sftp:// repository, does bazaar actually have to be installed on the host?
[08:18] <kisielk_home> or is it enough to have it just on the client?
[08:20] <luks> kisielk_home: no, it doesn't have to be on the server
[08:21] <luks> kisielk_home: only for bzr+ssh or bzr+http protocols
[08:21] <kisielk_home> nice
[08:21] <kisielk_home> yeah, I just want to keep some configuration files on my web server
[08:21] <kisielk_home> and sync them to the machines I use
[08:21] <kisielk_home> but it's shared hosting, so no bzr installed there
[08:21] <luks> should work fine
[08:22] <kisielk_home> cool
[08:34] <vila> jam: When you'll come online, have a look at the last comment in bzrlib.tests.test_log.TestShowlog.test_simple_log :-/
[10:55] <robsta> hi
[10:55] <robsta> what's the best changelog script with bzr, prepare-ChangeLog.pl seems not to handle it
[11:54] <robsta> jelmer: thanks for the fresh bzr-svn deb on the ppa, i can now clone my svn repo and `bzr check' works
[11:56] <jelmer> robsta: n/p
[11:57] <jelmer> robsta: what's prepare-ChangeLog.pl exactly, is it GNOME-specific?
[11:57] <robsta> nothing, it doesn't do bzr at all
[11:57] <robsta> (my version at least)
[11:58] <jelmer> I think there was a plugin that could write GNU-like ChangeLog entries
[11:58] <robsta> interesting
[11:58] <robsta> i'm really only using the script to create commit messages
[11:59] <jelmer> ah, it creates commit messages from the changelog rather than the other way around?
[12:00] <jelmer> in that case, the plugin won't be of much use to you
[12:00] <robsta> i run prepare-ChangeLog.pl, then paste it when committing
[12:00] <robsta> the changelog is just a side-product of that
[12:13] <asabil> robsta: you probably want to use moap instead of prepare-ChangeLog.pl
[12:13] <asabil> I have a patched version of moap that produces the exact same output
[12:13] <robsta> asabil: with function names?
[12:14] <asabil> ah, no I don't think so :/
[12:15] <robsta> :(
[12:15] <robsta> seems like maintainer.py doesn't to bzr either
[12:16] <asabil> well, I only used moap with Vala, so I don't know if it tries to extract function names for C code
[12:28] <robsta> heck, how hard can it be to hack prepare-ChangeLog.pl ...
[14:07] <Sadr> Bazaar is mainly designed for code, correct? But, could it be also used for, say, model/asset revisions tied up with a web-based GUI?
[15:04] <Sadr> second try... any examples of Bazaar being used for *files* (e.g. a .blend or .max) ?
[15:05] <Sadr> we're looking into maybe using Bazaar as an advanced file manager for our open source website
[15:05] <jelmer> Sadr: hi
[15:05] <jelmer> Sadr: The obvious problem with binary files is merging - bazaar does line-based merging
[15:05] <jelmer> other than that, it should work fine
[15:07] <Sadr> I see
[15:08] <awilkins> Ok ; here's a talking point ; tags
[15:10] <awilkins> All tags are replicated between branches on a push, pull, branch, even if they are on dead revisions
[15:10] <awilkins> e.g.
[15:11] <awilkins> bzr init one ; cd one ; echo one > one ; bzr add ; bzr commit -m "One ; bzr tag ONE ; bzr uncommit --force ; bzr commit -m "Two" ; bzr tag TWO ; cd .. ; bzr branch one two ; cd two ; bzr tags
[15:12] <awilkins> Dang, missing a quote
[15:12] <jelmer> awilkins: I think it's intentional to keep those
[15:12] <awilkins> jelmer: But then you have a tag that marks a revision that potentially does not exist in the target branch / repo
[15:12] <awilkins> jelmer: Dead revisions are not branched to the other branch, what's the sense in identifying them.
[15:14] <awilkins> In my case, I then ran into tag conflicts with new revisions (the tags are being generated by a script for metadata purposes)
[15:14] <Odd_Bloke> awilkins: 'bzr branch -rtag:dead-revision <original branch>'?
[15:15] <awilkins> Odd_Bloke: 'spose... :-)    it does seem rather marginal
[15:16] <Odd_Bloke> awilkins: Sure, but if the tag disappears, you don't know that you haven't got all of the revisions that were tagged.
[15:16] <Odd_Bloke> And presumably the tag still existed for a reason.
[15:16] <awilkins> I shouldn't run into it again, my script now overwrites the tags ; and people shouldn't push before they are sure they are not going to uncommit.
[15:17] <awilkins> The tag exists to identify live revisions that represent places to do a fancy diff report
[15:17] <jelmer> wow, has_revision() really profits from the 1.9 formats..
[15:20] <vila> jam: ping
[15:25] <derekS> hi all. just a quick question. what is the difference between committing to a local branch and pushing to a local folder?
[15:26] <derekS> not used to this dvcs :)
[15:26] <Odd_Bloke> derekS: You push commits.
[15:26] <Odd_Bloke> You commit changes.
[15:27] <Odd_Bloke> So push recreates your branch wherever you push to.
[15:27] <Odd_Bloke> Your branch doesn't include anything that hasn't been committed.
[15:27] <derekS> Odd_Bloke: so pushing a commit just merges it upstream?
[15:28] <awilkins> derekS: pushing only works if no merge is required :-)
[15:28] <Odd_Bloke> Nope, merging is a different concept.
[15:28] <derekS> so, pushing just puts my branch upstream?
[15:28] <derekS> so it copies my branch to the one i pushed to?
[15:28] <Odd_Bloke> What do you mean by 'upstream'?  Pushing just puts your branch wherever you're pushing to.
[15:29] <awilkins> pushing sends your revisions to the target branch, if it has no revisions that are children of the common ancestor you share
[15:29] <derekS> hmm gotcha
[15:29] <derekS> sorry, i am gjust trying to figure out how i can switch my svn to bzr
[15:29] <derekS> the owrkflow part
[15:29] <derekS> i use svn right now as a pseudo document management system :)
[15:30] <derekS> for my personal files
[15:30] <awilkins> Heh, I found it liberated me from the workflow of svn :)
[15:30] <awilkins> No having-to-be-in-the-office or on-the-vpn
[15:30] <awilkins> Started off with SVK and when that had a major oops, moved onto bazaar
[15:30] <derekS> awilkins: yeah :) i like it
[15:31] <derekS> just trying to create my workflow
[15:32] <awilkins> That reminds me... I was going to have a crack at bzr-svn 0.5 on this monster repo to see how it does compared to 0.4
[15:32]  * awilkins gets busy downloading stuff
[15:32] <derekS> have fun!
[17:29] <pickscrape> Is it possible to create a patch using bzr send which is against an earlier revision on the branch without having to bzr branch -r that revision out temporarily?
[17:30] <pickscrape> e.g. I have a branch that I submitted at r50, and I commit 5 more changes (to r51) and want to submit those 5 changes as a new patch but not including the work up to r50.
[17:30] <LeoNerd> Presumablly -r50..51 ?
[17:31] <pickscrape> Doesn't defining a range like that create a cherry pick?
[17:31] <LeoNerd> Yes. But that's what you're doing here
[17:32] <pickscrape> OK, asking my colleague to try that. Thanks :)
[17:33] <pickscrape> Related question, but when using a loom is there a simple way to say "send this thread" or does that also require looking at log and specifying the relevant revisions?
[17:38] <jam> vila: pong, sorry about the delay
[17:39] <vila> jam: np, just a quick chat about but #300055
[17:39] <vila> jam: np, just a quick chat about bug #300055
[17:39] <vila> gee ubottu, can't you see that I mixed up your nick and bug ?
[17:40] <vila> jam: So, as said in the bug comments, I commited 2 fixes already, cleaned up the tests (finding a semi-bogus one on the way)
[17:41] <vila> And I'm now to the point where I realized there are still problems lying around
[17:41] <jam> well, making things better than they are now is worth merging
[17:42] <jam> even if you don't have an absolute solution
[17:43] <vila> That was my feeling but I wanted to discuss a bit to clarify my mind, I want to send the submission with some explanations to start the discussion
[17:44] <vila> Roughly, we tend to enlarge the revision ranges to include the mainline revisions
[17:46] <vila> I think this is motivated by two facts: 1) that made the programming easier (wrong reason :), 2) we display dotted revnos *after* the mainline revisions they are merge into
[17:46] <vila> 2) does not play play well for several reasons
[17:48] <vila> a) it makes the code *harder* as soon as the revision ranges are not "complete" (as including the mainline revision and all its merged revisions)
[17:48] <synic> what is the equivalent of "bzr checkout" in bzrlib?  WorkingTree doesn't have a 'checkout' method
[17:49] <vila> b) the display is ill-defined when the range is not complete
[17:49] <jam> synic: Branch.create_checkout, IIRC, you can look in 'builtins.py' for the 'cmd_checkout' class
[17:49] <synic> ok
[17:50] <vila> The root cause being that reverse_by_depth works in one direction only and this went unnoticed until now, so many cases are not covered
[17:50] <vila> err, scratch that
[17:51] <jam> so let's start at the beginning
[17:51] <vila> The root cause being that reverse_by_depth works in one direction only, this went unnoticed until now but it was used in several places ignoring that fact
[17:51] <jam> "we tend to enlarge the revision ranges to include the mainline revisions"
[17:51] <vila> ok
[17:51] <jam> we want to go from a revision in the ancestry
[17:51] <jam> and track where it was merged until we get down to mainline
[17:51] <jam> merge-sorted revisions have this information easily available
[17:52] <jam> reversed... not so much
[17:52] <jam> I couldn't actually work out an obvious answer once they have been reversed.
[17:52] <vila> I argue that we may not want to do that unconditionally
[17:53] <jam> vila: perhaps, but for now it was chosen as the best trade off
[17:53] <jam> between showing all cases where the change was merged into
[17:53] <jam> and showing none
[17:53] <jam> it is logically an optional thing
[17:53] <jam> but to make it *actually* optional
[17:53] <jam> requires updating the UI
[17:53] <jam> and passing the parameters across the stack
[17:53] <jam> which is generally non-trivial
[17:54] <jam> It most certainly *can* be done. It wasn't worth my time
[17:54] <jam> and I would argue it isn't worth your time *right now*
[17:54] <jam> changing log so that it doesn't have to access as much ancestry would be a better thing to work on
[17:54] <jam> and that may restructure the code anwyay
[17:54] <jam> anyway
[17:55] <vila> jam: sorry, phone, back in a few minutes
[17:56] <vila> jam: back
[17:57] <jam> np
[17:57] <vila> Ok, I see your point. Yet, the case reported, starting at a dotted revno and fixed as of today allows to avoid showing a bunch of revisions (~50 or 100) so there is some motivation to handle it to respect user request
[17:59] <vila> But, you're right, I may submit the actual fixes and just add a note that some more work may be needed, the fixes themselves provides a better solution but doesn't address all the cases either
[18:01] <vila> Oh, re-reading your comments, I don't argue that we must not include the mainline revs, just that we don't have to include them if they are outside the requested range, i.e. at start/end only. But doing so raises some problems in the way we display them:
[18:02] <vila> We can display hanging revisions (without their mainline) at start, but we can't to that at end, because there isn't a mainline rev to aggregate them there
[18:02] <jam> vila: I don't quite see how you can get a revision that is in the ancestry that never ends up merged to a mainline revision
[18:03] <jam> it... wouldn't be in your ancestry if that was the case
[18:03] <vila> So doing 'log x.n.m..y.p.q' and 'log x.n.m..y.p.q --forward' can't display the same revisions
[18:03] <vila> the revision *is* in the ancestry but the range *excludes* it
[18:03] <jam> well, we only do the projection to mainline revs if you are logging a file
[18:05] <vila> Look at lp:~/vila/bzr/300055-log-forward, bzrlib/tests/test_log.py TestGetViewRevisions.test_file_id_for_range for an example or try the reported case with my fix
[18:06] <vila> in the reported case, the first required revision is 1616.70.54 which was merged in 1627
[18:06] <vila> Yet, with my fix and --forward, we don't display 1627
[18:07] <vila> but we display it *without* --forward
[18:07] <vila> A bit hard to explain :-/
[18:08] <jam> no, I understand what you mean
[18:08] <jam> IMO being consistent would be nice
[18:08] <jam> and I would probably go for "always show it"
[18:09] <jam> because I think it would be easier
[18:09] <vila> :-)
[18:11] <vila> Right, now, we understand each other I think :-) Easier for the dev may not be what the user is wanting, but the user may want other things first ! Does that summarize the discussion ?
[18:21] <jam> vila: yep
[18:21] <jam> Getting a "correct if suboptimal" result for log
[18:21] <jam> is the most important
[18:21] <jam> and getting other stuff done is better than optimizing the rest of log
[18:23] <vila> ok. I call it a day then (started a 6h30 this morning :)
[18:23] <vila> have a nice week-end !
[18:25] <LarstiQ> vila: you too!
[18:37] <jam> you too vila
[20:21] <jam> does anyone know if LP can handle 1.9 format branches yet?
[20:22] <beuno> jam, IIRC, it only has up to 1.8
[20:23] <beuno> actually, it's on 1.7.1rc1
[20:23] <beuno> so... only if used through sftp maybe?
[20:24] <beuno> I don't know how picky the smart server is about formats it doesn't know
[20:24] <jam> I don't think it can mirror branches from sftp => http side if it doesn't understand them
[20:25] <jam> and I don't think it can mirror a branch on my webserver if I upgraded it to 1.9 either
[20:25] <beuno> right, the puller will probably b0rk
[20:25] <jam> you would be able to *push* to bzr+ssh the first time
[20:25] <jam> and then future access will likely give "Unknown Format" errors
[20:25] <Peng_> Yeah, the puller can't mirror from 1.9 branches.
[20:25] <Peng_> (on external web servers, I mean)
[20:25] <jam> Perhaps if you used nosmart+bzr+ssh or some other crazy workaround like that
[20:27] <jam> which I suppose isn't terrible considering if you were using 1.9 it would trigger the auto-stack from LP, and we know that is a little bit buggy right now
[20:27] <jam> I'm trying to finish up Martin's fix and get it merged.
[20:29] <beuno> oh, that would be great
[20:29] <beuno> then we just push everyone to use nightly
[20:36] <jam> well, I think Martin wants to make sure things are going smooth
[20:36] <jam> and then have it all in 1.10rc1  which will be on Friday
[20:36] <jam> (1 week)
[21:34] <synic> how can I create a hook that only runs when a certain branch is pushed to?
[21:45] <freewilly1> Client-side? Use post_push. For server-side, you'll have to use post_change_branch_tip
[21:47] <freewilly1> I bet there's a way to check which branch is being operated on, but I don't know enough to answer that
[21:48] <synic> ok, yeah, that's what I'm looking for is which branch it is
[23:29] <synic> jam: ping
[23:37] <jfroy|work> Anyone here has setup some manner of automated Subversion Bazaar mirroring solution?
[23:38] <jfroy|work> Curious about people's experience, solutions, gotchas, and so on.