=== sabdfl1 is now known as sabdfl === sabdfl1 is now known as sabdfl [00:59] I think I'm hitting a bug in bzr-svn 0.5 RC1 === Mario__ is now known as pygi [01:00] bzr: ERROR: exceptions.AttributeError: 'NoneType' object has no attribute 'uuid' [01:00] enigma, I think there's an open report about that one [01:00] OK. Are those reported in the same place as bzr bug? [01:00] Or is there a separate bug tracker for bzr-svn? [01:00] launchpad.net/bzr-svn [01:01] OK. Let me look it up. [01:07] jelmer: It looks like those errors come up when the bzr properties are missing. I created the svn branch using "svn copy", is that why it doesn't have bzr properties? [01:08] based on the tracebacks in that bug report at least, it can't be related to bzr propeties [01:09] it's a problem in the way bzr-svn follows the svn log to find out the branch history [01:09] unfortunately I can't reproduce it here [01:09] Which bug report are you looking at? [01:09] I found: https://bugs.launchpad.net/bzr-svn/+bug/177383 [01:09] Launchpad bug 177383 in bzr-svn "traceback when importing svn tree: 'NoneType' object has no attribute 'splitlines' (dup-of: 174690)" [Undecided,New] [01:09] Launchpad bug 174690 in bzr-svn ""pull" should handle removal of bzr:ancestry property" [Low,Fix released] [01:10] enigma, that's not the same bug [01:10] And: https://bugs.launchpad.net/bzr-svn/+bug/206728 [01:10] Launchpad bug 206728 in bzr-svn ""'NoneType' object has no attribute 'splitlines'" crash in checkout" [Undecided,Fix released] [01:13] https://bugs.edge.launchpad.net/bzr-svn/+bug/306288 [01:13] Launchpad bug 306288 in bzr-svn "pulling a previously branched SVN repo with no local commits causes a "branches have diverged" error" [Undecided,New] [01:15] Oh...this is what I did...I have a few hundred revisions I pulled down using bzr-svn 0.4.15. I then pushed those revisions into a brand new repository. [01:15] I then upgraded to bzr-svn 0.5 RC1 and pulled those revisions from the brand new svn repo. [01:15] (using bzr to pull it) [01:16] I do a commit on the branch. [01:16] I then try to "push" back to that new svn repo and that's when I get the error. [01:16] (And yes, I cleared the svn-cache and subversion.conf after moving 0.5 RC1) [01:18] Is the bzr:* properties that are created with bzr-svn 0.4 incompatible with bzr-svn 0.5? [01:19] no, they should work ok [01:19] though there could be a bug there [01:19] of course [01:20] hi hi folks [01:21] jelmer: OK...now I'm reverting to 0.4.16 and I'll try the same commit with a push back to svn. === davi_ is now known as davi [01:21] (After clearing svn-cache and all that) [01:23] Hm...now if I revert, I get this: bzr: ERROR: exceptions.KeyError [01:23] Sorry, I just re-read that and I don't think it's clear. [01:24] What I mean is...now if I try the commit back to the same svn repo using bzr-svn 0.4.16 instead of 0.5 RC1 I get that "KeyError" [01:24] enigma, can you pastebin the full backtrace? [01:24] enigma, were some revisions already pushed using 0.5rc1? [01:25] Not that I can recall.... [01:25] I'm pretty sure it was all push with 0.4.16... [01:26] You want me to recreate the SVN repo from scratch with 0.4.16 to make sure? [01:26] (Where's the pastebin?) [01:26] pastebin.ubuntu.com [01:29] http://pastebin.ubuntu.com/84616/ [01:33] I think that's actually a bug that's fixed in 0.5.. [01:33] Oh, OK. :-D [01:34] I'm recreating the svn repo using 0.4.16. [01:34] Then I'm going to switch to 0.5 RC1 and see if I can get that "uuid" error again. [01:41] I'm getting another exception with 0.4.16, might this be a bug? bzr: ERROR: bzrlib.errors.NoSuchRevision: apCache object at 0x88c328c> has no revision enigma@neumannc-desktop-20081202021 [01:41] 216-yyxr9acya83v2rjt [01:42] I got the tree I'm trying to push from another svn repo. [01:43] And now I'm doing this: bzr push -v --overwrite svn+http://localhost/svn/test/trunk/gui [01:48] Oh...this is strange... [01:49] If I push just the first rev it works fine: bzr push -r 1 -v --overwrite svn+http://localhost/svn/test/trunk/gui [01:49] But pushing 386 revs doesn't work. [01:50] After pushing the first rev with "overwrite", I can do a "normal" push, but I get segfaults. [01:50] bzr push -v --overwrite svn+http://localhost/svn/test/trunk/gui [01:50] The svn+ syntax is deprecated, use http://localhost/svn/test/trunk/gui instead. [01:50] \ [=== ] pushing revisions 25/385Segmentation fault [01:51] jelmer: Even though I got a segfault, I can push some more... [01:51] jelmer: But then I get another segfault after 44 revs... [01:52] After restarting the push about 5 times, I get all revision into svn. [01:52] enigma, but that's using 0.4 ? [01:52] Right. this is with 0.4. Want me to try with 0.5? [01:53] I'll go through the same steps with the same repo. [01:54] Yeah, I get the same behavior with 0.5 RC1 [01:54] same being that error about uuid ? [01:55] Sorry...haven't gotten to the uuid error. [01:55] I'm getting a NoSuchRevision error when I'm trying to recreate my svn repo. [01:56] Quick recap: zapped the svn repo which I was using that was giving me a "uuid" error. [01:56] Started recreating the repo from scratch. [01:56] That brought up this other bug which I encountered before but had forgotten about. [01:56] And it appears this bug is in 0.4 and 0.5 [01:58] This is for the NoSuchRevision error: http://pastebin.ubuntu.com/84623/ [01:59] Work around is... [01:59] do this: bzr push -r 1 -v --overwrite svn+http://localhost/svn/test/trunk/gui [02:00] But the work around only seems to work for 0.4.16 [02:01] any chance you can file a bug about this? [02:01] Sure. === Mario__ is now known as pygi === Mario__ is now known as pygi [02:13] OK, here's the new bug report for the "NoSuchRevision" error (which exists for both 0.4 and 0.5): https://bugs.launchpad.net/bzr-svn/+bug/307611 [02:13] Launchpad bug 307611 in bzr-svn "Pushing lots of revisions from one svn repo to another results in bzrlib.errors.NoSuchRevision" [Undecided,New] [02:14] enigma, the repository is private, I presume ? [02:14] Unfortunately, yeah. [02:14] I wish I could share. ;-) === Mario__ is now known as pygi [02:25] jelmer: Is there a bzr-svn equivalent of "bzr check"? [02:25] well, you can run "bzr check" on a svn branch but it won't do much [02:25] Is there something that can "check" the bzr:* properties on an svn repo? [02:26] That sort of thing? [02:26] nope [02:26] OK. [02:26] there's probably something going wrong recording the contents of enigma@neumannc-desktop-20081202021216-yyxr9acya83v2rjt [02:26] is it a merge revision or something? What sort of changes does it contain? [02:27] How do I see? [02:29] I tried: bzr log -r enigma@neumannc-desktop-20081202021216-yyxr9acya83v2rjt [02:29] that doesn't seem to work [02:31] bzr log -rrevid:enigma@neumannc-desktop-20081202021216-yyxr9acya83v2rjt [02:31] should work [02:32] Oh, OK...trying... [02:32] No...it wasn't a merge... [02:33] Just a plain commit... [02:34] Is there a way to rebuild the map? [02:34] enigma, what sort of changes does it contain? [02:34] enigma, which map? [02:34] The bzrlib.plugins.svn.revids.RevisionIdMapCache [02:34] That map. [02:34] it's part of the cache [02:35] so after you remove the cache, the map will be empty (and it gets filled lazily) [02:35] Oh...I see what might be going on.... [02:36] I did this: bzr branch svn+http;//remote/svn/trunk/gui gui-trunk [02:36] then I did this: bzr branch gui-trunk gui [02:36] After which I cleared my cache. [02:37] And then I tried to push the versions into: http://localhost/svn/trunk/gui [02:37] Which is a totally different server. [02:37] not sure I follow.. [02:38] And if I do a bzr info on "gui", it only knows about "gui-trunk" and not the original svn server. [02:38] So it will never tried to rebuild the map. [02:38] Which I purged from the cache. [02:39] In short, I did a "pull" from server A and then a push to server B. [02:39] that should work just fine [02:39] However, after doing the "pull", I remove the svn-cache (due to experiementing with other things) [02:40] The "push" to server B isn't rebuilding the RevisionIdMapCache for server A. [02:40] Just for server B. [02:40] there's no reason why it should [02:40] we don't need the cache for A in that situation anyway [02:40] Oh, OK. [02:41] So why would I get an error about a particular revision not being in the RevisionIdMapCache? [02:41] If the cache isn't used? [02:41] to bzr-svn, those revisions are just like ordinary bzr revisions [02:41] or should be, at least [02:42] Why would that revision id be expected to be in the RevisionIdMapCache at all then since I haven't pushed it to server B and the RevisionIdMapCache for server A shouldn't be used? [02:43] it's thinking one of the children of that revision has to be pushed and that revision itself is already present [02:43] so when it crashes, it hasn't pushed that particular revision yet? [02:43] what is the revision id of the children of that revision? [02:44] Right. That the latest revision in the repo. [02:44] There are not children of that revision...it's just a straight up commit. [02:45] Correction...it's the -2 revision, not the -1 revision. [02:45] Second most recent rev. [02:46] what's the revision id of the last revision? [02:46] Is there a nice way to get a revid from a revno? [02:46] bzr log --show-ids -r [02:46] Cool, thanks. It's not in the help for log. [02:46] Oh wait...yes it is...I missed it...sorry. [02:47] revno: 385 [02:47] revision-id: enigma@neumannc-desktop-20081202021216-yyxr9acya83v2rjt [02:47] parent: enigma@neumannc-desktop-20081202014850-fgbyjkv8rqfbdm23 [02:47] What's the "parent"? [02:48] In this case, the "parent" is the previous revision. [02:48] the parent is the revision the revision was basd on [02:48] OK. [02:48] there can be multiple parents in thecase of a merge [02:48] OK. [02:48] but what's the revision id of the last revision? [02:49] revno: 386 [02:49] revision-id: enigma@neumannc-desktop-20081202023059-gzdv3fvxklm0v1z4 [02:49] parent: enigma@neumannc-desktop-20081202021216-yyxr9acya83v2rjt [02:49] So, I'm not seeing anything weird about rev 386 or 385 or 384.... [02:49] is that revision a merge revision perhaps? [02:50] No...the last merge in the history was at rev 378 [02:50] jelmer: don't suppose you have a good list of new stuff in the bzr-svn 0.5.x series? [02:51] rocky, see NEWS [02:51] enigma, strange [02:53] I have exactly 4 merges in the whole history. [02:54] And doing a "push -r 1" works just fine. [02:54] enigma, is this 0.5.0rc1 or 0.5 ? [02:54] This is 0.4.16 in this case. [02:54] enigma, push -r1 would push the first revision in history, so that's a noop :-) [02:54] jelmer: ah thanks ... [02:54] With 0.5 RC1 I get a different error. [02:54] Well...sort of... [02:54] ah, what's the error in that case? [02:54] I get the same error for "push --overwrite" [02:55] But I get a different error for "push -r 1" [02:55] I mean... [02:55] "push -r 1 --overwrite" [02:55] I posted both the 0.4.16 error and the 0.5 RC1 error on: https://bugs.launchpad.net/bzr-svn/+bug/307611 [02:55] Launchpad bug 307611 in bzr-svn "Pushing lots of revisions from one svn repo to another results in bzrlib.errors.NoSuchRevision" [Undecided,New] [02:55] They are both in the block at the top. [02:56] They kind of run together...probably needed some more whitespace between them. [02:56] I mean with "bzr push -r1 --overwrite" on 0.5 [02:57] OK...let me get that error and post in on the bug report...one sec. [02:58] (bugs in 0.4 are not likely to be fixed anymore, I'm focussing on 0.5) [02:59] (Makes sense.) [03:01] OK, look at my most recent comment here: https://bugs.launchpad.net/bzr-svn/+bug/307611 [03:01] Launchpad bug 307611 in bzr-svn "Pushing lots of revisions from one svn repo to another results in bzrlib.errors.NoSuchRevision" [Undecided,New] [03:01] I get an AssertError with 0.5 RC1 [03:02] bzr: ERROR: exceptions.AssertionError: revprops: ['bzr:revision-id', 'bzr:user-agent', 'bzr:timestamp', 'bzr:root', 'bzr:committer', 'svn:log', 'bzr:revprop:branch-nick', 'bzr:file-ids', 'bzr:base-revision', 'bzr:revno', 'bzr:mapping-version'] [03:02] ah, that's been fixed in the 0.5 branch [03:02] So should I get the truck for 0.5 instead of RC1? [03:03] yeah [03:03] http://people.samba.org/bzr/jelmer/bzr-svn/0.5 [03:05] OK, let me grab it. [03:06] i was just about to play with 0.5rc1 .. should i skip it and just try 0.5 branch ? [03:09] jelmer: python setup.py install doesn't appear to work with 0.5rc1 :( [03:11] basically it looks like the subvertpy package doesn't get installed [03:12] jelmer: OK, the latest bzr-svn 0.5 fixed that assert error. [03:13] It did not, however, fix the missing revision error. [03:13] So that seems like it's still a bug. [03:14] Ah ha! I got the "uuid" error again: bzr: ERROR: exceptions.AttributeError: 'NoneType' object has no attribute 'uuid' [03:14] That was after pushing just one revision. [03:14] enigma: how are you installing 0.5rc1 (or the branch?) ... the used-to-work-with-0.4.x "python setup.py install" doesn't seem to work for me [03:14] Oh, I just run it out of "~/.bazaar/plugins/svn" [03:15] I do a "make" [03:15] And then copy it to the plugins directory. [03:15] I don't do a sitewide install. [03:15] rocky, that's also fixed in the 0.5 branch [03:16] lol [03:17] enigma, at the risk of asking the same question twice.. [03:18] enigma, the backtrace in bug 307611 for 0.5 was produced by pushing into a fresh svn repository? [03:18] Launchpad bug 307611 in bzr-svn "Pushing lots of revisions from one svn repo to another results in bzrlib.errors.NoSuchRevision" [Undecided,New] https://launchpad.net/bugs/307611 [03:18] yes, a fresh repo. [03:18] enigma, with fresh repo you mean "svnadmin create ..", right? [03:18] yeah. [03:19] ok (since you mentioned "svn mkdir" in the bugreport) [03:19] I had one commit to make "trunk" [03:19] And one commit to make "trunk/gui" [03:19] So, the svn repo was at v2 when I tried the "push --overwrite" [03:19] So here's something strange with 0.5-trunk... [03:20] I'm being told wrong svn info now: [03:20] revno: 1 [03:20] svn revno: 4684 (on /trunk/press-gui) [03:20] committer: Christoph Neumann [03:20] So, after sucessfully doing this: bzr push -r 1 -v --overwrite svn+http://localhost/svn/test/trunk/gui [03:20] enigma, that looks alright if you ran "bzr push -r1 --overwrite" [03:20] I did this: bzr branch svn+http://localhost/svn/test/trunk/gui [03:21] Which is *really* strange because the svn repo is at rev 3 now. [03:21] yes, but you pushed only one bzr revision, right? [03:21] Yeah, so why is it telling 4684? [03:22] enigma, that's derived from the revision id [03:23] That was the right svn revision for the repo the change came from. [03:23] But the new repo is now at rev 3. [03:23] enigma, what does "svn info" on http://localhost/svn/test/trunk/gui say? [03:23] svn info http://localhost/svn/test/trunk/gui [03:23] Path: gui [03:23] URL: http://localhost/svn/test/trunk/gui [03:23] Repository Root: http://localhost/svn/test [03:23] Repository UUID: 27530666-c0bc-4525-b9dd-495b6ed8d586 [03:23] Revision: 3 [03:23] Node Kind: directory [03:23] Last Changed Rev: 3 [03:23] Last Changed Date: 2008-12-12 19:17:26 -0800 (Fri, 12 Dec 2008) [03:24] hmm [03:24] * jelmer has to get some sleep [03:24] I'll have another look at your bug report tomorrow [03:24] sorry [03:24] No problem. [03:24] thanks for the help debugging, at least [03:24] I'll see if I can get in IRC tomorrow. [03:24] If you have more questions. [03:24] Thanks for all your help! [03:24] cool, that could be useful [03:24] I learned lots of stuff. [03:24] I'll try to reply in the bugreport as well [03:24] g'night! [03:24] OK. Goodnight. [03:48] is it possible to list all revids in a repository? [04:17] jml: yo [04:18] lifeless: hey there [04:20] jml: so testresources has a bunc of 'fix committted' stuff. [04:20] I'm wondering if 'its in trunk' is good enough [04:21] lifeless: good enough for what? [04:21] for us [04:23] lifeless: are you wondering whether we should do releases? [04:23] kinda [04:23] lifeless: I've been using "fix commited" in the bzr project sense. [04:23] lifeless: i.e. "there's a branch with a fix" [04:23] hmm [04:23] think some bugs are mislabelled then [04:26] lifeless: it's possible. [04:26] lifeless: I haven't done a round of gardening for a while. [04:28] lifeless: also, my laptop battery is dying and I'm not near power. [04:30] jml: ok, I have what I need - I'll use test released for stuff in trunk [04:30] jml: thanks [04:30] lifeless: I've just reviewed the third of the four subunit branches marked for review. [04:31] lifeless: I'll get to the fourth soon. [04:31] "polish" hasn't been submitted for review either. [04:31] * jml suspends. [05:52] does launchpad have bzr-cia? [07:08] jml: thanks [08:02] I'm running the bzr 1.5 on Debian. I only use it for syncing a heap of text files between a few machines. Is there anything to be gained by compiling and installing 1.10? [11:17] I'd like to understand why this bug isn't being treated too seriously: https://bugs.launchpad.net/bzr/+bug/113809 [11:17] Launchpad bug 113809 in bzr "update performs two merges" [High,Confirmed] [11:17] Is there a workaround I'm missing? [11:17] How can users do local commits without having to worry about this? [11:53] does anybody knows about something like `bzr chdir` command? to change directory before run arbitrary command and then chdir back? [11:53] bialix: just change your actual directory [11:54] bialix: and many commands allow explicit definition of a directory [11:54] I need this for batch processing. [11:54] but missing is not [11:54] https://bugs.launchpad.net/bzr/+bug/207762/ [11:54] Launchpad bug 207762 in bzr "missing does not accept "-d" parameter" [Low,Confirmed] [11:55] bialix: I don't see why actually changing your directory would be a problem [11:55] because I'm working on scmproj plugin that operates on the set of bzr branches as unite project [11:56] I've implemented project-command command to run some command for all branches in the project in one loop [11:56] bialix: I still don't understand why you can't run "cd" instead of your desired "bzr chdir" command [11:56] but `bzr missing` is unable to run in this way [11:57] because of design of my plugin. [11:59] actually I'm already implemented chdr command, I'm just wonder is not I'm reinventing the wheel, or does anybody else needs such feature. [11:59] bialix: and your plugin could run something like "bzr chdir"? [11:59] yes, I'm just finished it [12:00] in the past I remember that `bzr status` is also behaves differently either it runs as `bzr status .` or without any arguments. [12:01] bialix: I know several bzr commands interpret "." as an argument differently than nothing, especially add [12:01] bialix: add only uses ignores without an argument [12:01] yep [12:21] Er, not exactly. Add only uses ignores for discovered items, not given items. [12:21] fullermd: And if you give it an argument, you're using a "given item." [12:22] Yes, but add can still discover items (e.g., 'bzr add .' will recurse and discover items, to which ignores will be applied. But they won't be for '.' itself, only for the discovered ones.) [12:22] Maybe I was thinking bzr add * [12:22] but that's only one level different [12:23] * fullermd nods. [12:23] So that will add an ignored subdir, but not add anything _within_ it (which can be a little confuzzling) [12:23] fullermd: Agreed, especially when you're coming from svn [12:23] Wait, that's wrong. I'm thinking of a different case. [12:24] * bialix likes "confuzzling" :-) [12:24] Ignoring the subdir doesn't ignore the files within it. I'm thinking of cases where I ignore '*' [12:24] * fullermd aims to please ;) [12:25] bialix: you're familiar with the -d option on a number of commands? [12:25] bialix: in my and mwhudson's opinion at least, that should be supported on more commands [12:26] LarstiQ: yes, I'm aware about -d. But `bzr missing` lacks it [12:26] fullermd: Then I'll give you a fresh opportunity. I'm trying to figure out the best Bazaar workflow for next week's Drupal code sprint. It's all the core Drupal developers. If Bazaar handles things smoothly, I think it may strongly influence Drupal's next choice of VCS> [12:26] bialix: right, so my vote is for missing to be modified to support it. How exactly does your `bzr chdir` work? [12:27] I'm just wanna say that you could provide valid non-local URL to -d, so --directory name for this option is actually bad name [12:27] cwd = os.getcwdu() [12:27] os.chdir(directory) [12:27] fullermd: Given the terribly flawed implementation of commit --local, I need a smooth way for developers to commit changes locally (to a branch, likely) but still push changes centrally [12:27] try: [12:27] bialix: hmmm. That won't work for commands needing a workingtree, would it? [12:27] return run_bzr(argv_list) [12:27] finally: [12:28] os.chdir(cwd) [12:28] bialix: (giving a non-local url to -d) [12:28] LarstiQ: most of the command that supports -d works with the branch, not WT [12:28] fullermd: The problem with bzr push is that it modifies the central repository history [12:28] fullermd: and that's sort of evil [12:28] bialix: I'm thinking of merge specifically [12:29] fullermd: I can make the central repository "append-revisions-only", but then diverged branches can't be pushed [12:29] davidstrauss: you can set a branch config to not reorder the mainline. [12:29] right [12:29] yes, you're right; merge is exception here [12:30] LarstiQ: So, is there any solution other than the terribly clunky combination of checkout and branch for each developer? [12:30] bialix: so you'd use bzr chdir by writing your normal command, and then sticking chdir between 'bzr ' and the rest? [12:31] davidstrauss: I'm not entirely sure what you're trying to solve. [12:31] davidstrauss: since to me, reordering the mainline is not evil. [12:31] LarstiQ: yes [12:31] Well, that's the sorta setup I always use. I've not found it especially clunky, but then I don't run into offline conditions often. [12:31] LarstiQ: I guess I don't understand how the reordering affects the mainline [12:31] why not? [12:32] Not when I'm doing something I'd put right on trunk, anyway. [12:32] davidstrauss: but, if I understand you correctly, merge the diverged branch into trunk. And the checkout helps in not racing. [12:32] bialix: okay, that approach will work with any and all commands, which is a plus. [12:32] bialix: I don't find it too elegant though :/ [12:32] LarstiQ: exactly [12:33] LarstiQ: How does the mainline get reordered? Does it use the revnos from the branch that was pushed? [12:33] LarstiQ: well, it's a 5 minute hack to provide workaround [12:33] davidstrauss: it will use the ordering of the pushing branch, yes [12:33] davidstrauss: The revnos are dependant on what the head rev is (rather, the history implied by it) [12:33] bialix: right [12:33] it may be confusing, but it's a matter of taste [12:34] * LarstiQ nods [12:34] bzr cd foo/bar missing http://foo.net/branch [12:34] So, how should other developers get changes from the central branch, pull or merge? If they pull, then their local revnos change, too, right? [12:35] well, it actually need to train the eye [12:35] davidstrauss: right [12:35] LarstiQ: So should local devs merge? [12:35] (from the mainline) [12:35] davidstrauss: depends on what they want to do [12:35] davidstrauss: personally, I'd just pull. [12:36] But if there's divergence, you have to merge first, right? [12:36] davidstrauss: that could go two directions though [12:36] LarstiQ: the merge? [12:36] davidstrauss: they could merge their stuff into trunk, commit, and then pull from trunk [12:37] instead of merging trunk into their branch [12:37] How do people on a development team communicate about revision numbers if they're unstable? [12:38] bialix: on the -d side, it would be nice if this operation was the same on all commands, but it would also be nice if you could use the '-d' branch without a working directory. Hmmm [12:38] davidstrauss: right, that is the question you need to ask. How much is that worth to you? [12:38] I think it's worth a lot to have consistent revision numbers for communication [12:39] LarstiQ: sometimes I think -d is misdesigned [12:39] davidstrauss: One answer could be: revnos are instantaneous, they lose their validity after a (short) amount of time [12:39] especially re tag command [12:39] LarstiQ: like process IDs on unix [12:40] davidstrauss: that's a nice analogy [12:40] bialix: how so? [12:41] davidstrauss: if you want to use them in bugreports that might be open for a couple of weeks, then it becomes more important that they be stable. [12:41] IMO bzr tag TAGNAME URL is good enough [12:41] davidstrauss: so there you could do two things afaics, one is to refer to revision ids, not revision numbers. The other would be to base the revnos on a branch where the mainline does not get reordered. [12:42] as I mentioned i nthe mailing list I think we need a "standard option" -d which works the same for all commands [12:42] AmanicA: some commands don;t need -d, e.g. status, diff, commit, add [12:43] revision IDs are 100% stable, right? [12:43] davidstrauss: yes [12:43] yes but for scripting purposes, I think it'l be nice to have a consitant interface for all commands [12:43] Is there a way to detect whether a revision ID has been integrated into a branch? [12:43] may be you're right; but having 2 ways to express things... confuzzling? [12:44] (Other than bzr log --show-ids|grep ID) [12:44] davidstrauss: bzrlib wise or command line wise? [12:44] command line wise [12:44] You could use revision-info maybe. [12:45] (there's no "yes/no" giving command, but you can use side effects like "does this work". [12:45] that would be my guess as well. [12:45] or bzr missing [12:46] Hm. Well, OK, you can use revision-info and see if it blows up and gives you a traceback :| [12:46] Cobalt:a straussd$ bzr revision-info "david@fourkitchens.com-20081213120349-g6y28op35qnf3rhe" [12:46] bzr: ERROR: No namespace registered for string: u'david@fourkitchens.com-20081213120349-g6y28op35qnf3rhe' [12:46] that's what I get [12:47] with or without quotes around the revision id [12:47]