[00:24] poolie: I'm up for a call. [00:28] hi [00:28] on skype or something, if you like? [00:37] poolie: http://code.aaronbentley.com/bzr/bzrrepo/288751-pack-deltas [00:52] how do i handle "Contents conflict", the file has been renamed in the current tree [00:58] how do I change the format of a branch from BranchFormat7 to BranchFormat6? [01:00] maybe bzr upgrade? [01:01] jbalint: see "bzr help conflicts" [01:01] jbalint: a contents conflict is when bzr sees conflicting changes to a non-text file. [01:02] Or the addition of a file with the same path [01:02] hrm, these shouldnt be nontext [01:02] In two seperate branches [01:02] one is .h, its the exact files taht are renamted [01:04] awilkins: Hmm, "bzr help conflicts" suggests that would reported differently. [01:05] Note that symlinks and directories count as non-text files... [01:05] I've never seen a "path" conflict, only content ones [01:06] And these are for ASCII text files [01:06] Maybe it's a windows thing? [01:06] Maybe, I wouldn't know. [01:47] what is the shortest sequence of commands to give me the equivalent of hg addremove? [01:51] kingfishr: something like "bzr add; bzr commit" IIRC (commit will automatically remove missing files by default, I think). [01:52] oh really? [01:52] that's convenient [01:52] i wasn't aware of that [01:53] I think --strict will disable that behaviour. Try it out, it's easy to experiment : [01:53] :) === ubott2 is now known as ubottu [02:21] jam, are you still around? did you do a patch towards bug 300177, i don't remember [02:21] Launchpad bug 300177 in bzr "get_record_stream/ContentFactory should expose compression parents" [High,Confirmed] https://launchpad.net/bugs/300177 [02:38] 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] I had heard tell that gitosis may support bzr [02:39] or maybe I'm thinging of something else [02:40] hrmm, not in it's current state [02:42] bzr_access is the closest I know if. [02:42] s/if/of/ [02:43] ok, cool [05:22] Gooood morning all [05:26] vila: good morning. [05:26] vila: you seem to be around early today :) [05:26] spiv: no, check your clock :) [05:26] kidding, I dropped my girlfriend to the airport :) [05:31] hi ,i have a problem with bzr-svn, [05:33] bzr 1.9 bzr-svn 0.4.15, check out http://www.prestashop.com/publicsvn ,error === doko_ is now known as doko [08:18] 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] or is it enough to have it just on the client? [08:20] kisielk_home: no, it doesn't have to be on the server [08:21] kisielk_home: only for bzr+ssh or bzr+http protocols [08:21] nice [08:21] yeah, I just want to keep some configuration files on my web server [08:21] and sync them to the machines I use [08:21] but it's shared hosting, so no bzr installed there [08:21] should work fine [08:22] cool [08:34] jam: When you'll come online, have a look at the last comment in bzrlib.tests.test_log.TestShowlog.test_simple_log :-/ === thekorn_ is now known as thekorn === kiko-afk is now known as kiko [10:55] hi [10:55] what's the best changelog script with bzr, prepare-ChangeLog.pl seems not to handle it === bac is now known as bac_afk [11:54] jelmer: thanks for the fresh bzr-svn deb on the ppa, i can now clone my svn repo and `bzr check' works [11:56] robsta: n/p [11:57] robsta: what's prepare-ChangeLog.pl exactly, is it GNOME-specific? [11:57] nothing, it doesn't do bzr at all [11:57] (my version at least) [11:58] I think there was a plugin that could write GNU-like ChangeLog entries [11:58] interesting [11:58] i'm really only using the script to create commit messages [11:59] ah, it creates commit messages from the changelog rather than the other way around? [12:00] in that case, the plugin won't be of much use to you [12:00] i run prepare-ChangeLog.pl, then paste it when committing [12:00] the changelog is just a side-product of that [12:13] robsta: you probably want to use moap instead of prepare-ChangeLog.pl [12:13] I have a patched version of moap that produces the exact same output [12:13] asabil: with function names? [12:14] ah, no I don't think so :/ [12:15] :( [12:15] seems like maintainer.py doesn't to bzr either [12:16] well, I only used moap with Vala, so I don't know if it tries to extract function names for C code [12:28] heck, how hard can it be to hack prepare-ChangeLog.pl ... === kiko is now known as kiko-fud [14:07] 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? === kiko-fud is now known as kiko-afk [15:04] second try... any examples of Bazaar being used for *files* (e.g. a .blend or .max) ? [15:05] we're looking into maybe using Bazaar as an advanced file manager for our open source website [15:05] Sadr: hi [15:05] Sadr: The obvious problem with binary files is merging - bazaar does line-based merging [15:05] other than that, it should work fine [15:07] I see [15:08] Ok ; here's a talking point ; tags [15:10] All tags are replicated between branches on a push, pull, branch, even if they are on dead revisions [15:10] e.g. [15:11] 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] Dang, missing a quote [15:12] awilkins: I think it's intentional to keep those [15:12] jelmer: But then you have a tag that marks a revision that potentially does not exist in the target branch / repo [15:12] jelmer: Dead revisions are not branched to the other branch, what's the sense in identifying them. [15:14] 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] awilkins: 'bzr branch -rtag:dead-revision '? [15:15] Odd_Bloke: 'spose... :-) it does seem rather marginal [15:16] 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] And presumably the tag still existed for a reason. [15:16] 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] The tag exists to identify live revisions that represent places to do a fancy diff report [15:17] wow, has_revision() really profits from the 1.9 formats.. [15:20] jam: ping [15:25] hi all. just a quick question. what is the difference between committing to a local branch and pushing to a local folder? [15:26] not used to this dvcs :) [15:26] derekS: You push commits. [15:26] You commit changes. [15:27] So push recreates your branch wherever you push to. [15:27] Your branch doesn't include anything that hasn't been committed. [15:27] Odd_Bloke: so pushing a commit just merges it upstream? [15:28] derekS: pushing only works if no merge is required :-) [15:28] Nope, merging is a different concept. [15:28] so, pushing just puts my branch upstream? [15:28] so it copies my branch to the one i pushed to? [15:28] What do you mean by 'upstream'? Pushing just puts your branch wherever you're pushing to. [15:29] pushing sends your revisions to the target branch, if it has no revisions that are children of the common ancestor you share [15:29] hmm gotcha [15:29] sorry, i am gjust trying to figure out how i can switch my svn to bzr [15:29] the owrkflow part [15:29] i use svn right now as a pseudo document management system :) [15:30] for my personal files [15:30] Heh, I found it liberated me from the workflow of svn :) [15:30] No having-to-be-in-the-office or on-the-vpn [15:30] Started off with SVK and when that had a major oops, moved onto bazaar [15:30] awilkins: yeah :) i like it [15:31] just trying to create my workflow [15:32] 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] have fun! === abadger19991 is now known as abagder1999 === abagder1999 is now known as abadger19991 === abadger19991 is now known as abadger1999 === sdboyer is now known as sdboyer|class [17:29] 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] 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] Presumablly -r50..51 ? [17:31] Doesn't defining a range like that create a cherry pick? [17:31] Yes. But that's what you're doing here [17:32] OK, asking my colleague to try that. Thanks :) [17:33] 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] vila: pong, sorry about the delay [17:39] jam: np, just a quick chat about but #300055 [17:39] jam: np, just a quick chat about bug #300055 [17:39] Launchpad bug 300055 in bzr ""bzr log --forward FILE" crashes for revision range if first revision is not mainline" [Medium,In progress] https://launchpad.net/bugs/300055 [17:39] gee ubottu, can't you see that I mixed up your nick and bug ? [17:40] 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] And I'm now to the point where I realized there are still problems lying around [17:41] well, making things better than they are now is worth merging [17:42] even if you don't have an absolute solution [17:43] 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] Roughly, we tend to enlarge the revision ranges to include the mainline revisions [17:46] 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] 2) does not play play well for several reasons [17:48] 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] what is the equivalent of "bzr checkout" in bzrlib? WorkingTree doesn't have a 'checkout' method [17:49] b) the display is ill-defined when the range is not complete [17:49] synic: Branch.create_checkout, IIRC, you can look in 'builtins.py' for the 'cmd_checkout' class [17:49] ok [17:50] 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] err, scratch that [17:51] so let's start at the beginning [17:51] 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] "we tend to enlarge the revision ranges to include the mainline revisions" [17:51] ok [17:51] we want to go from a revision in the ancestry [17:51] and track where it was merged until we get down to mainline [17:51] merge-sorted revisions have this information easily available [17:52] reversed... not so much [17:52] I couldn't actually work out an obvious answer once they have been reversed. [17:52] I argue that we may not want to do that unconditionally [17:53] vila: perhaps, but for now it was chosen as the best trade off [17:53] between showing all cases where the change was merged into [17:53] and showing none [17:53] it is logically an optional thing [17:53] but to make it *actually* optional [17:53] requires updating the UI [17:53] and passing the parameters across the stack [17:53] which is generally non-trivial [17:54] It most certainly *can* be done. It wasn't worth my time [17:54] and I would argue it isn't worth your time *right now* [17:54] changing log so that it doesn't have to access as much ancestry would be a better thing to work on [17:54] and that may restructure the code anwyay [17:54] anyway [17:55] jam: sorry, phone, back in a few minutes [17:56] jam: back [17:57] np [17:57] 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] 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] 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] 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] 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] it... wouldn't be in your ancestry if that was the case [18:03] 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] the revision *is* in the ancestry but the range *excludes* it [18:03] well, we only do the projection to mainline revs if you are logging a file === jdong_ is now known as jdong [18:05] 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] in the reported case, the first required revision is 1616.70.54 which was merged in 1627 [18:06] Yet, with my fix and --forward, we don't display 1627 [18:07] but we display it *without* --forward [18:07] A bit hard to explain :-/ [18:08] no, I understand what you mean [18:08] IMO being consistent would be nice [18:08] and I would probably go for "always show it" [18:09] because I think it would be easier [18:09] :-) [18:11] 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] vila: yep [18:21] Getting a "correct if suboptimal" result for log [18:21] is the most important [18:21] and getting other stuff done is better than optimizing the rest of log [18:23] ok. I call it a day then (started a 6h30 this morning :) [18:23] have a nice week-end ! [18:25] vila: you too! [18:37] you too vila === sdboyer|class is now known as sdboyer [20:21] does anyone know if LP can handle 1.9 format branches yet? [20:22] jam, IIRC, it only has up to 1.8 [20:23] actually, it's on 1.7.1rc1 [20:23] so... only if used through sftp maybe? [20:24] I don't know how picky the smart server is about formats it doesn't know [20:24] I don't think it can mirror branches from sftp => http side if it doesn't understand them [20:25] and I don't think it can mirror a branch on my webserver if I upgraded it to 1.9 either [20:25] right, the puller will probably b0rk [20:25] you would be able to *push* to bzr+ssh the first time [20:25] and then future access will likely give "Unknown Format" errors [20:25] Yeah, the puller can't mirror from 1.9 branches. [20:25] (on external web servers, I mean) [20:25] Perhaps if you used nosmart+bzr+ssh or some other crazy workaround like that [20:27] 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] I'm trying to finish up Martin's fix and get it merged. [20:29] oh, that would be great [20:29] then we just push everyone to use nightly [20:36] well, I think Martin wants to make sure things are going smooth [20:36] and then have it all in 1.10rc1 which will be on Friday [20:36] (1 week) [21:34] how can I create a hook that only runs when a certain branch is pushed to? [21:45] Client-side? Use post_push. For server-side, you'll have to use post_change_branch_tip [21:47] I bet there's a way to check which branch is being operated on, but I don't know enough to answer that === freewilly1 is now known as kumi1 [21:48] ok, yeah, that's what I'm looking for is which branch it is === jfroy|work is now known as jfroy === jfroy is now known as jfroy|work [23:29] jam: ping [23:37] Anyone here has setup some manner of automated Subversion Bazaar mirroring solution? [23:38] Curious about people's experience, solutions, gotchas, and so on.