| === sabdfl1 is now known as sabdfl | ||
| === sabdfl1 is now known as sabdfl | ||
| enigma | I think I'm hitting a bug in bzr-svn 0.5 RC1 | 00:59 |
|---|---|---|
| === Mario__ is now known as pygi | ||
| enigma | bzr: ERROR: exceptions.AttributeError: 'NoneType' object has no attribute 'uuid' | 01:00 |
| jelmer | enigma, I think there's an open report about that one | 01:00 |
| enigma | OK. Are those reported in the same place as bzr bug? | 01:00 |
| enigma | Or is there a separate bug tracker for bzr-svn? | 01:00 |
| jelmer | launchpad.net/bzr-svn | 01:00 |
| enigma | OK. Let me look it up. | 01:01 |
| enigma | 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:07 |
| jelmer | based on the tracebacks in that bug report at least, it can't be related to bzr propeties | 01:08 |
| jelmer | it's a problem in the way bzr-svn follows the svn log to find out the branch history | 01:09 |
| jelmer | unfortunately I can't reproduce it here | 01:09 |
| enigma | Which bug report are you looking at? | 01:09 |
| enigma | I found: https://bugs.launchpad.net/bzr-svn/+bug/177383 | 01:09 |
| ubottu | Launchpad bug 177383 in bzr-svn "traceback when importing svn tree: 'NoneType' object has no attribute 'splitlines' (dup-of: 174690)" [Undecided,New] | 01:09 |
| ubottu | Launchpad bug 174690 in bzr-svn ""pull" should handle removal of bzr:ancestry property" [Low,Fix released] | 01:09 |
| jelmer | enigma, that's not the same bug | 01:10 |
| enigma | And: https://bugs.launchpad.net/bzr-svn/+bug/206728 | 01:10 |
| ubottu | Launchpad bug 206728 in bzr-svn ""'NoneType' object has no attribute 'splitlines'" crash in checkout" [Undecided,Fix released] | 01:10 |
| jelmer | https://bugs.edge.launchpad.net/bzr-svn/+bug/306288 | 01:13 |
| ubottu | 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:13 |
| enigma | 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 |
| enigma | I then upgraded to bzr-svn 0.5 RC1 and pulled those revisions from the brand new svn repo. | 01:15 |
| enigma | (using bzr to pull it) | 01:15 |
| enigma | I do a commit on the branch. | 01:16 |
| enigma | I then try to "push" back to that new svn repo and that's when I get the error. | 01:16 |
| enigma | (And yes, I cleared the svn-cache and subversion.conf after moving 0.5 RC1) | 01:16 |
| enigma | Is the bzr:* properties that are created with bzr-svn 0.4 incompatible with bzr-svn 0.5? | 01:18 |
| jelmer | no, they should work ok | 01:19 |
| jelmer | though there could be a bug there | 01:19 |
| jelmer | of course | 01:19 |
| pygi | hi hi folks | 01:20 |
| enigma | jelmer: OK...now I'm reverting to 0.4.16 and I'll try the same commit with a push back to svn. | 01:21 |
| === davi_ is now known as davi | ||
| enigma | (After clearing svn-cache and all that) | 01:21 |
| enigma | Hm...now if I revert, I get this: bzr: ERROR: exceptions.KeyError | 01:23 |
| enigma | Sorry, I just re-read that and I don't think it's clear. | 01:23 |
| enigma | 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 |
| jelmer | enigma, can you pastebin the full backtrace? | 01:24 |
| jelmer | enigma, were some revisions already pushed using 0.5rc1? | 01:24 |
| enigma | Not that I can recall.... | 01:25 |
| enigma | I'm pretty sure it was all push with 0.4.16... | 01:25 |
| enigma | You want me to recreate the SVN repo from scratch with 0.4.16 to make sure? | 01:26 |
| enigma | (Where's the pastebin?) | 01:26 |
| jelmer | pastebin.ubuntu.com | 01:26 |
| enigma | http://pastebin.ubuntu.com/84616/ | 01:29 |
| jelmer | I think that's actually a bug that's fixed in 0.5.. | 01:33 |
| enigma | Oh, OK. :-D | 01:33 |
| enigma | I'm recreating the svn repo using 0.4.16. | 01:34 |
| enigma | Then I'm going to switch to 0.5 RC1 and see if I can get that "uuid" error again. | 01:34 |
| enigma | I'm getting another exception with 0.4.16, might this be a bug? bzr: ERROR: bzrlib.errors.NoSuchRevision: <bzrlib.plugins.svn.revids.RevisionIdM | 01:41 |
| enigma | apCache object at 0x88c328c> has no revision enigma@neumannc-desktop-20081202021 | 01:41 |
| enigma | 216-yyxr9acya83v2rjt | 01:41 |
| enigma | I got the tree I'm trying to push from another svn repo. | 01:42 |
| enigma | And now I'm doing this: bzr push -v --overwrite svn+http://localhost/svn/test/trunk/gui | 01:43 |
| enigma | Oh...this is strange... | 01:48 |
| enigma | 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 |
| enigma | But pushing 386 revs doesn't work. | 01:49 |
| enigma | After pushing the first rev with "overwrite", I can do a "normal" push, but I get segfaults. | 01:50 |
| enigma | bzr push -v --overwrite svn+http://localhost/svn/test/trunk/gui | 01:50 |
| enigma | The svn+ syntax is deprecated, use http://localhost/svn/test/trunk/gui instead. | 01:50 |
| enigma | \ [=== ] pushing revisions 25/385Segmentation fault | 01:50 |
| enigma | jelmer: Even though I got a segfault, I can push some more... | 01:51 |
| enigma | jelmer: But then I get another segfault after 44 revs... | 01:51 |
| enigma | After restarting the push about 5 times, I get all revision into svn. | 01:52 |
| jelmer | enigma, but that's using 0.4 ? | 01:52 |
| enigma | Right. this is with 0.4. Want me to try with 0.5? | 01:52 |
| enigma | I'll go through the same steps with the same repo. | 01:53 |
| enigma | Yeah, I get the same behavior with 0.5 RC1 | 01:54 |
| jelmer | same being that error about uuid ? | 01:54 |
| enigma | Sorry...haven't gotten to the uuid error. | 01:55 |
| enigma | I'm getting a NoSuchRevision error when I'm trying to recreate my svn repo. | 01:55 |
| enigma | Quick recap: zapped the svn repo which I was using that was giving me a "uuid" error. | 01:56 |
| enigma | Started recreating the repo from scratch. | 01:56 |
| enigma | That brought up this other bug which I encountered before but had forgotten about. | 01:56 |
| enigma | And it appears this bug is in 0.4 and 0.5 | 01:56 |
| enigma | This is for the NoSuchRevision error: http://pastebin.ubuntu.com/84623/ | 01:58 |
| enigma | Work around is... | 01:59 |
| enigma | do this: bzr push -r 1 -v --overwrite svn+http://localhost/svn/test/trunk/gui | 01:59 |
| enigma | But the work around only seems to work for 0.4.16 | 02:00 |
| jelmer | any chance you can file a bug about this? | 02:01 |
| enigma | Sure. | 02:01 |
| === Mario__ is now known as pygi | ||
| === Mario__ is now known as pygi | ||
| enigma | 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 |
| ubottu | Launchpad bug 307611 in bzr-svn "Pushing lots of revisions from one svn repo to another results in bzrlib.errors.NoSuchRevision" [Undecided,New] | 02:13 |
| jelmer | enigma, the repository is private, I presume ? | 02:14 |
| enigma | Unfortunately, yeah. | 02:14 |
| enigma | I wish I could share. ;-) | 02:14 |
| === Mario__ is now known as pygi | ||
| enigma | jelmer: Is there a bzr-svn equivalent of "bzr check"? | 02:25 |
| jelmer | well, you can run "bzr check" on a svn branch but it won't do much | 02:25 |
| enigma | Is there something that can "check" the bzr:* properties on an svn repo? | 02:25 |
| enigma | That sort of thing? | 02:26 |
| jelmer | nope | 02:26 |
| enigma | OK. | 02:26 |
| jelmer | there's probably something going wrong recording the contents of enigma@neumannc-desktop-20081202021216-yyxr9acya83v2rjt | 02:26 |
| jelmer | is it a merge revision or something? What sort of changes does it contain? | 02:26 |
| enigma | How do I see? | 02:27 |
| enigma | I tried: bzr log -r enigma@neumannc-desktop-20081202021216-yyxr9acya83v2rjt | 02:29 |
| enigma | that doesn't seem to work | 02:29 |
| jelmer | bzr log -rrevid:enigma@neumannc-desktop-20081202021216-yyxr9acya83v2rjt | 02:31 |
| jelmer | should work | 02:31 |
| enigma | Oh, OK...trying... | 02:32 |
| enigma | No...it wasn't a merge... | 02:32 |
| enigma | Just a plain commit... | 02:33 |
| enigma | Is there a way to rebuild the map? | 02:34 |
| jelmer | enigma, what sort of changes does it contain? | 02:34 |
| jelmer | enigma, which map? | 02:34 |
| enigma | The bzrlib.plugins.svn.revids.RevisionIdMapCache | 02:34 |
| enigma | That map. | 02:34 |
| jelmer | it's part of the cache | 02:34 |
| jelmer | so after you remove the cache, the map will be empty (and it gets filled lazily) | 02:35 |
| enigma | Oh...I see what might be going on.... | 02:35 |
| enigma | I did this: bzr branch svn+http;//remote/svn/trunk/gui gui-trunk | 02:36 |
| enigma | then I did this: bzr branch gui-trunk gui | 02:36 |
| enigma | After which I cleared my cache. | 02:36 |
| enigma | And then I tried to push the versions into: http://localhost/svn/trunk/gui | 02:37 |
| enigma | Which is a totally different server. | 02:37 |
| jelmer | not sure I follow.. | 02:37 |
| enigma | And if I do a bzr info on "gui", it only knows about "gui-trunk" and not the original svn server. | 02:38 |
| enigma | So it will never tried to rebuild the map. | 02:38 |
| enigma | Which I purged from the cache. | 02:38 |
| enigma | In short, I did a "pull" from server A and then a push to server B. | 02:39 |
| jelmer | that should work just fine | 02:39 |
| enigma | However, after doing the "pull", I remove the svn-cache (due to experiementing with other things) | 02:39 |
| enigma | The "push" to server B isn't rebuilding the RevisionIdMapCache for server A. | 02:40 |
| enigma | Just for server B. | 02:40 |
| jelmer | there's no reason why it should | 02:40 |
| jelmer | we don't need the cache for A in that situation anyway | 02:40 |
| enigma | Oh, OK. | 02:40 |
| enigma | So why would I get an error about a particular revision not being in the RevisionIdMapCache? | 02:41 |
| enigma | If the cache isn't used? | 02:41 |
| jelmer | to bzr-svn, those revisions are just like ordinary bzr revisions | 02:41 |
| jelmer | or should be, at least | 02:41 |
| enigma | 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:42 |
| jelmer | it's thinking one of the children of that revision has to be pushed and that revision itself is already present | 02:43 |
| jelmer | so when it crashes, it hasn't pushed that particular revision yet? | 02:43 |
| jelmer | what is the revision id of the children of that revision? | 02:43 |
| enigma | Right. That the latest revision in the repo. | 02:44 |
| enigma | There are not children of that revision...it's just a straight up commit. | 02:44 |
| enigma | Correction...it's the -2 revision, not the -1 revision. | 02:45 |
| enigma | Second most recent rev. | 02:45 |
| jelmer | what's the revision id of the last revision? | 02:46 |
| enigma | Is there a nice way to get a revid from a revno? | 02:46 |
| jelmer | bzr log --show-ids -r<revno> | 02:46 |
| enigma | Cool, thanks. It's not in the help for log. | 02:46 |
| enigma | Oh wait...yes it is...I missed it...sorry. | 02:46 |
| enigma | revno: 385 | 02:47 |
| enigma | revision-id: enigma@neumannc-desktop-20081202021216-yyxr9acya83v2rjt | 02:47 |
| enigma | parent: enigma@neumannc-desktop-20081202014850-fgbyjkv8rqfbdm23 | 02:47 |
| enigma | What's the "parent"? | 02:47 |
| enigma | In this case, the "parent" is the previous revision. | 02:48 |
| jelmer | the parent is the revision the revision was basd on | 02:48 |
| enigma | OK. | 02:48 |
| jelmer | there can be multiple parents in thecase of a merge | 02:48 |
| enigma | OK. | 02:48 |
| jelmer | but what's the revision id of the last revision? | 02:48 |
| enigma | revno: 386 | 02:49 |
| enigma | revision-id: enigma@neumannc-desktop-20081202023059-gzdv3fvxklm0v1z4 | 02:49 |
| enigma | parent: enigma@neumannc-desktop-20081202021216-yyxr9acya83v2rjt | 02:49 |
| enigma | So, I'm not seeing anything weird about rev 386 or 385 or 384.... | 02:49 |
| jelmer | is that revision a merge revision perhaps? | 02:49 |
| enigma | No...the last merge in the history was at rev 378 | 02:50 |
| rocky | jelmer: don't suppose you have a good list of new stuff in the bzr-svn 0.5.x series? | 02:50 |
| jelmer | rocky, see NEWS | 02:51 |
| jelmer | enigma, strange | 02:51 |
| enigma | I have exactly 4 merges in the whole history. | 02:53 |
| enigma | And doing a "push -r 1" works just fine. | 02:54 |
| jelmer | enigma, is this 0.5.0rc1 or 0.5 ? | 02:54 |
| enigma | This is 0.4.16 in this case. | 02:54 |
| jelmer | enigma, push -r1 would push the first revision in history, so that's a noop :-) | 02:54 |
| rocky | jelmer: ah thanks ... | 02:54 |
| enigma | With 0.5 RC1 I get a different error. | 02:54 |
| enigma | Well...sort of... | 02:54 |
| jelmer | ah, what's the error in that case? | 02:54 |
| enigma | I get the same error for "push --overwrite" | 02:54 |
| enigma | But I get a different error for "push -r 1" | 02:55 |
| enigma | I mean... | 02:55 |
| enigma | "push -r 1 --overwrite" | 02:55 |
| enigma | 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 |
| ubottu | 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 |
| enigma | They are both in the block at the top. | 02:55 |
| enigma | They kind of run together...probably needed some more whitespace between them. | 02:56 |
| jelmer | I mean with "bzr push -r1 --overwrite" on 0.5 | 02:56 |
| enigma | OK...let me get that error and post in on the bug report...one sec. | 02:57 |
| jelmer | (bugs in 0.4 are not likely to be fixed anymore, I'm focussing on 0.5) | 02:58 |
| enigma | (Makes sense.) | 02:59 |
| enigma | OK, look at my most recent comment here: https://bugs.launchpad.net/bzr-svn/+bug/307611 | 03:01 |
| ubottu | 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 |
| enigma | I get an AssertError with 0.5 RC1 | 03:01 |
| enigma | 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 |
| jelmer | ah, that's been fixed in the 0.5 branch | 03:02 |
| enigma | So should I get the truck for 0.5 instead of RC1? | 03:02 |
| jelmer | yeah | 03:03 |
| jelmer | http://people.samba.org/bzr/jelmer/bzr-svn/0.5 | 03:03 |
| enigma | OK, let me grab it. | 03:05 |
| rocky | i was just about to play with 0.5rc1 .. should i skip it and just try 0.5 branch ? | 03:06 |
| rocky | jelmer: python setup.py install doesn't appear to work with 0.5rc1 :( | 03:09 |
| rocky | basically it looks like the subvertpy package doesn't get installed | 03:11 |
| enigma | jelmer: OK, the latest bzr-svn 0.5 fixed that assert error. | 03:12 |
| enigma | It did not, however, fix the missing revision error. | 03:13 |
| enigma | So that seems like it's still a bug. | 03:13 |
| enigma | Ah ha! I got the "uuid" error again: bzr: ERROR: exceptions.AttributeError: 'NoneType' object has no attribute 'uuid' | 03:14 |
| enigma | That was after pushing just one revision. | 03:14 |
| rocky | 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 |
| enigma | Oh, I just run it out of "~/.bazaar/plugins/svn" | 03:14 |
| enigma | I do a "make" | 03:15 |
| enigma | And then copy it to the plugins directory. | 03:15 |
| enigma | I don't do a sitewide install. | 03:15 |
| jelmer | rocky, that's also fixed in the 0.5 branch | 03:15 |
| rocky | lol | 03:16 |
| jelmer | enigma, at the risk of asking the same question twice.. | 03:17 |
| jelmer | enigma, the backtrace in bug 307611 for 0.5 was produced by pushing into a fresh svn repository? | 03:18 |
| ubottu | 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 |
| enigma | yes, a fresh repo. | 03:18 |
| jelmer | enigma, with fresh repo you mean "svnadmin create ..", right? | 03:18 |
| enigma | yeah. | 03:18 |
| jelmer | ok (since you mentioned "svn mkdir" in the bugreport) | 03:19 |
| enigma | I had one commit to make "trunk" | 03:19 |
| enigma | And one commit to make "trunk/gui" | 03:19 |
| enigma | So, the svn repo was at v2 when I tried the "push --overwrite" | 03:19 |
| enigma | So here's something strange with 0.5-trunk... | 03:19 |
| enigma | I'm being told wrong svn info now: | 03:20 |
| enigma | revno: 1 | 03:20 |
| enigma | svn revno: 4684 (on /trunk/press-gui) | 03:20 |
| enigma | committer: Christoph Neumann <enigma@qbert> | 03:20 |
| enigma | So, after sucessfully doing this: bzr push -r 1 -v --overwrite svn+http://localhost/svn/test/trunk/gui | 03:20 |
| jelmer | enigma, that looks alright if you ran "bzr push -r1 --overwrite" | 03:20 |
| enigma | I did this: bzr branch svn+http://localhost/svn/test/trunk/gui | 03:20 |
| enigma | Which is *really* strange because the svn repo is at rev 3 now. | 03:21 |
| jelmer | yes, but you pushed only one bzr revision, right? | 03:21 |
| enigma | Yeah, so why is it telling 4684? | 03:21 |
| jelmer | enigma, that's derived from the revision id | 03:22 |
| enigma | That was the right svn revision for the repo the change came from. | 03:23 |
| enigma | But the new repo is now at rev 3. | 03:23 |
| jelmer | enigma, what does "svn info" on http://localhost/svn/test/trunk/gui say? | 03:23 |
| enigma | svn info http://localhost/svn/test/trunk/gui | 03:23 |
| enigma | Path: gui | 03:23 |
| enigma | URL: http://localhost/svn/test/trunk/gui | 03:23 |
| enigma | Repository Root: http://localhost/svn/test | 03:23 |
| enigma | Repository UUID: 27530666-c0bc-4525-b9dd-495b6ed8d586 | 03:23 |
| enigma | Revision: 3 | 03:23 |
| enigma | Node Kind: directory | 03:23 |
| enigma | Last Changed Rev: 3 | 03:23 |
| enigma | Last Changed Date: 2008-12-12 19:17:26 -0800 (Fri, 12 Dec 2008) | 03:23 |
| jelmer | hmm | 03:24 |
| * jelmer has to get some sleep | 03:24 | |
| jelmer | I'll have another look at your bug report tomorrow | 03:24 |
| jelmer | sorry | 03:24 |
| enigma | No problem. | 03:24 |
| jelmer | thanks for the help debugging, at least | 03:24 |
| enigma | I'll see if I can get in IRC tomorrow. | 03:24 |
| enigma | If you have more questions. | 03:24 |
| enigma | Thanks for all your help! | 03:24 |
| jelmer | cool, that could be useful | 03:24 |
| enigma | I learned lots of stuff. | 03:24 |
| jelmer | I'll try to reply in the bugreport as well | 03:24 |
| jelmer | g'night! | 03:24 |
| enigma | OK. Goodnight. | 03:24 |
| Rolly | is it possible to list all revids in a repository? | 03:48 |
| lifeless | jml: yo | 04:17 |
| jml | lifeless: hey there | 04:18 |
| lifeless | jml: so testresources has a bunc of 'fix committted' stuff. | 04:20 |
| lifeless | I'm wondering if 'its in trunk' is good enough | 04:20 |
| jml | lifeless: good enough for what? | 04:21 |
| lifeless | for us | 04:21 |
| jml | lifeless: are you wondering whether we should do releases? | 04:23 |
| lifeless | kinda | 04:23 |
| jml | lifeless: I've been using "fix commited" in the bzr project sense. | 04:23 |
| jml | lifeless: i.e. "there's a branch with a fix" | 04:23 |
| lifeless | hmm | 04:23 |
| lifeless | think some bugs are mislabelled then | 04:23 |
| jml | lifeless: it's possible. | 04:26 |
| jml | lifeless: I haven't done a round of gardening for a while. | 04:26 |
| jml | lifeless: also, my laptop battery is dying and I'm not near power. | 04:28 |
| lifeless | jml: ok, I have what I need - I'll use test released for stuff in trunk | 04:30 |
| lifeless | jml: thanks | 04:30 |
| jml | lifeless: I've just reviewed the third of the four subunit branches marked for review. | 04:30 |
| jml | lifeless: I'll get to the fourth soon. | 04:31 |
| jml | "polish" hasn't been submitted for review either. | 04:31 |
| * jml suspends. | 04:31 | |
| meoblast001 | does launchpad have bzr-cia? | 05:52 |
| lifeless | jml: thanks | 07:08 |
| cammoblammo | 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? | 08:02 |
| davidstrauss | I'd like to understand why this bug isn't being treated too seriously: https://bugs.launchpad.net/bzr/+bug/113809 | 11:17 |
| ubottu | Launchpad bug 113809 in bzr "update performs two merges" [High,Confirmed] | 11:17 |
| davidstrauss | Is there a workaround I'm missing? | 11:17 |
| davidstrauss | How can users do local commits without having to worry about this? | 11:17 |
| bialix | does anybody knows about something like `bzr chdir` command? to change directory before run arbitrary command and then chdir back? | 11:53 |
| davidstrauss | bialix: just change your actual directory | 11:53 |
| davidstrauss | bialix: and many commands allow explicit definition of a directory | 11:54 |
| bialix | I need this for batch processing. | 11:54 |
| bialix | but missing is not | 11:54 |
| bialix | https://bugs.launchpad.net/bzr/+bug/207762/ | 11:54 |
| ubottu | Launchpad bug 207762 in bzr "missing does not accept "-d" parameter" [Low,Confirmed] | 11:54 |
| davidstrauss | bialix: I don't see why actually changing your directory would be a problem | 11:55 |
| bialix | because I'm working on scmproj plugin that operates on the set of bzr branches as unite project | 11:55 |
| bialix | I've implemented project-command command to run some command for all branches in the project in one loop | 11:56 |
| davidstrauss | bialix: I still don't understand why you can't run "cd" instead of your desired "bzr chdir" command | 11:56 |
| bialix | but `bzr missing` is unable to run in this way | 11:56 |
| bialix | because of design of my plugin. | 11:57 |
| bialix | 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 |
| davidstrauss | bialix: and your plugin could run something like "bzr chdir"? | 11:59 |
| bialix | yes, I'm just finished it | 11:59 |
| bialix | in the past I remember that `bzr status` is also behaves differently either it runs as `bzr status .` or without any arguments. | 12:00 |
| davidstrauss | bialix: I know several bzr commands interpret "." as an argument differently than nothing, especially add | 12:01 |
| davidstrauss | bialix: add only uses ignores without an argument | 12:01 |
| bialix | yep | 12:01 |
| fullermd | Er, not exactly. Add only uses ignores for discovered items, not given items. | 12:21 |
| davidstrauss | fullermd: And if you give it an argument, you're using a "given item." | 12:21 |
| fullermd | 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 |
| davidstrauss | Maybe I was thinking bzr add * | 12:22 |
| davidstrauss | but that's only one level different | 12:22 |
| * fullermd nods. | 12:23 | |
| fullermd | So that will add an ignored subdir, but not add anything _within_ it (which can be a little confuzzling) | 12:23 |
| davidstrauss | fullermd: Agreed, especially when you're coming from svn | 12:23 |
| fullermd | Wait, that's wrong. I'm thinking of a different case. | 12:23 |
| * bialix likes "confuzzling" :-) | 12:24 | |
| fullermd | 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:24 | |
| LarstiQ | bialix: you're familiar with the -d option on a number of commands? | 12:25 |
| LarstiQ | bialix: in my and mwhudson's opinion at least, that should be supported on more commands | 12:25 |
| bialix | LarstiQ: yes, I'm aware about -d. But `bzr missing` lacks it | 12:26 |
| davidstrauss | 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 |
| LarstiQ | bialix: right, so my vote is for missing to be modified to support it. How exactly does your `bzr chdir` work? | 12:26 |
| bialix | 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 |
| bialix | cwd = os.getcwdu() | 12:27 |
| bialix | os.chdir(directory) | 12:27 |
| davidstrauss | 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 |
| bialix | try: | 12:27 |
| LarstiQ | bialix: hmmm. That won't work for commands needing a workingtree, would it? | 12:27 |
| bialix | return run_bzr(argv_list) | 12:27 |
| bialix | finally: | 12:27 |
| bialix | os.chdir(cwd) | 12:28 |
| LarstiQ | bialix: (giving a non-local url to -d) | 12:28 |
| bialix | LarstiQ: most of the command that supports -d works with the branch, not WT | 12:28 |
| davidstrauss | fullermd: The problem with bzr push is that it modifies the central repository history | 12:28 |
| davidstrauss | fullermd: and that's sort of evil | 12:28 |
| LarstiQ | bialix: I'm thinking of merge specifically | 12:28 |
| davidstrauss | fullermd: I can make the central repository "append-revisions-only", but then diverged branches can't be pushed | 12:29 |
| LarstiQ | davidstrauss: you can set a branch config to not reorder the mainline. | 12:29 |
| LarstiQ | right | 12:29 |
| bialix | yes, you're right; merge is exception here | 12:29 |
| davidstrauss | LarstiQ: So, is there any solution other than the terribly clunky combination of checkout and branch for each developer? | 12:30 |
| LarstiQ | bialix: so you'd use bzr chdir by writing your normal command, and then sticking chdir between 'bzr ' and the rest? | 12:30 |
| LarstiQ | davidstrauss: I'm not entirely sure what you're trying to solve. | 12:31 |
| LarstiQ | davidstrauss: since to me, reordering the mainline is not evil. | 12:31 |
| bialix | LarstiQ: yes | 12:31 |
| fullermd | 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 |
| davidstrauss | LarstiQ: I guess I don't understand how the reordering affects the mainline | 12:31 |
| bialix | why not? | 12:31 |
| fullermd | Not when I'm doing something I'd put right on trunk, anyway. | 12:32 |
| LarstiQ | davidstrauss: but, if I understand you correctly, merge the diverged branch into trunk. And the checkout helps in not racing. | 12:32 |
| LarstiQ | bialix: okay, that approach will work with any and all commands, which is a plus. | 12:32 |
| LarstiQ | bialix: I don't find it too elegant though :/ | 12:32 |
| bialix | LarstiQ: exactly | 12:32 |
| davidstrauss | LarstiQ: How does the mainline get reordered? Does it use the revnos from the branch that was pushed? | 12:33 |
| bialix | LarstiQ: well, it's a 5 minute hack to provide workaround | 12:33 |
| LarstiQ | davidstrauss: it will use the ordering of the pushing branch, yes | 12:33 |
| fullermd | davidstrauss: The revnos are dependant on what the head rev is (rather, the history implied by it) | 12:33 |
| LarstiQ | bialix: right | 12:33 |
| bialix | it may be confusing, but it's a matter of taste | 12:33 |
| * LarstiQ nods | 12:34 | |
| bialix | bzr cd foo/bar missing http://foo.net/branch | 12:34 |
| davidstrauss | 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:34 |
| bialix | well, it actually need to train the eye | 12:35 |
| LarstiQ | davidstrauss: right | 12:35 |
| davidstrauss | LarstiQ: So should local devs merge? | 12:35 |
| davidstrauss | (from the mainline) | 12:35 |
| LarstiQ | davidstrauss: depends on what they want to do | 12:35 |
| LarstiQ | davidstrauss: personally, I'd just pull. | 12:35 |
| davidstrauss | But if there's divergence, you have to merge first, right? | 12:36 |
| LarstiQ | davidstrauss: that could go two directions though | 12:36 |
| davidstrauss | LarstiQ: the merge? | 12:36 |
| LarstiQ | davidstrauss: they could merge their stuff into trunk, commit, and then pull from trunk | 12:36 |
| LarstiQ | instead of merging trunk into their branch | 12:37 |
| davidstrauss | How do people on a development team communicate about revision numbers if they're unstable? | 12:37 |
| LarstiQ | 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 |
| LarstiQ | davidstrauss: right, that is the question you need to ask. How much is that worth to you? | 12:38 |
| davidstrauss | I think it's worth a lot to have consistent revision numbers for communication | 12:38 |
| bialix | LarstiQ: sometimes I think -d is misdesigned | 12:39 |
| LarstiQ | davidstrauss: One answer could be: revnos are instantaneous, they lose their validity after a (short) amount of time | 12:39 |
| bialix | especially re tag command | 12:39 |
| davidstrauss | LarstiQ: like process IDs on unix | 12:39 |
| LarstiQ | davidstrauss: that's a nice analogy | 12:40 |
| LarstiQ | bialix: how so? | 12:40 |
| LarstiQ | 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 |
| bialix | IMO bzr tag TAGNAME URL is good enough | 12:41 |
| LarstiQ | 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:41 |
| AmanicA | as I mentioned i nthe mailing list I think we need a "standard option" -d which works the same for all commands | 12:42 |
| bialix | AmanicA: some commands don;t need -d, e.g. status, diff, commit, add | 12:42 |
| davidstrauss | revision IDs are 100% stable, right? | 12:43 |
| LarstiQ | davidstrauss: yes | 12:43 |
| AmanicA | yes but for scripting purposes, I think it'l be nice to have a consitant interface for all commands | 12:43 |
| davidstrauss | Is there a way to detect whether a revision ID has been integrated into a branch? | 12:43 |
| bialix | may be you're right; but having 2 ways to express things... confuzzling? | 12:43 |
| davidstrauss | (Other than bzr log --show-ids|grep ID) | 12:44 |
| LarstiQ | davidstrauss: bzrlib wise or command line wise? | 12:44 |
| davidstrauss | command line wise | 12:44 |
| fullermd | You could use revision-info maybe. | 12:44 |
| fullermd | (there's no "yes/no" giving command, but you can use side effects like "does this work". | 12:45 |
| LarstiQ | that would be my guess as well. | 12:45 |
| LarstiQ | or bzr missing | 12:45 |
| fullermd | Hm. Well, OK, you can use revision-info and see if it blows up and gives you a traceback :| | 12:46 |
| davidstrauss | Cobalt:a straussd$ bzr revision-info "david@fourkitchens.com-20081213120349-g6y28op35qnf3rhe" | 12:46 |
| davidstrauss | bzr: ERROR: No namespace registered for string: u'david@fourkitchens.com-20081213120349-g6y28op35qnf3rhe' | 12:46 |
| davidstrauss | that's what I get | 12:46 |
| davidstrauss | with or without quotes around the revision id | 12:47 |
| fullermd | bzr revision-info -rrevid:a@b.c-1235 | 12:47 |
| davidstrauss | that works | 12:48 |
| davidstrauss | thanks | 12:48 |
| davidstrauss | How do other DVCS tools handle the issue of stable history on the main branch? | 12:48 |
| davidstrauss | I know most use the hash-based IDs as the primary revision tracking IDs. | 12:49 |
| LarstiQ | davidstrauss: right, that's how hg and git do it | 12:49 |
| LarstiQ | davidstrauss: there are some Linus quotes on revision numbers being a stupid idea even :) | 12:50 |
| davidstrauss | LarstiQ: I think I'm starting to agree with him | 12:50 |
| davidstrauss | I don't like that Bazaar gives the false impression that the numeric IDs will be stable. | 12:51 |
| LarstiQ | where? how? | 12:51 |
| LarstiQ | Revision numbers are stable in one branch only. | 12:51 |
| davidstrauss | LarstiQ: When you come from SVN or CVS, you're used to revision numbers never changing once set. | 12:52 |
| davidstrauss | LarstiQ: And, no, revision numbers are not stable even within one branch if you push to that branch. | 12:52 |
| fullermd | Well, it's not to do with revision numbers at all. | 12:52 |
| fullermd | Nobody else (TTBOMK) has a concept of a branch mainline at all. | 12:53 |
| davidstrauss | fullermd: pardon? | 12:53 |
| LarstiQ | davidstrauss: you just changed the branch there | 12:53 |
| LarstiQ | but yes, what fullermd said | 12:53 |
| fullermd | People who rail against bzr revnos always seem to miss that they're not the primary at all; they're an emergant property of the mainline concept. | 12:54 |
| davidstrauss | fullermd: Please explain. | 12:54 |
| davidstrauss | (or link me to something) | 12:54 |
| fullermd | The problem with fiddling the history isn't that the revnos get messy per se; it's that you lose the mainline, and so lose that extra tool (and because the UI is built assuming the usage of that tool in many ways, a lot of things get way less convenient) | 12:55 |
| davidstrauss | fullermd: Which extra tool? | 12:55 |
| fullermd | The mainline. | 12:55 |
| fullermd | Think of it as a way of winnowing down history. | 12:55 |
| fullermd | Would it be useful to run $VCS log, and get the revisions in your history in a randomized order? | 12:56 |
| davidstrauss | fullermd: obviously not | 12:56 |
| fullermd | Yah. So you need to sort them somehow. | 12:56 |
| fullermd | The "right" was is "in the order they belong", which is way too ill-defined to actually use. | 12:56 |
| fullermd | A good first approximation is chronological. | 12:57 |
| fullermd | That works great in a purely linear system like CVSVN. | 12:57 |
| davidstrauss | fullermd: So how does bzr order them if you have a sort-of mainline everyone pushes to? | 12:57 |
| fullermd | In a parallel system like a DVCS, it's a bit stickier, since a revision no longer has a unique "that came before me". | 12:57 |
| fullermd | So bzr imposes an extra structure of a 'mainline', which is defined by the left (or first, whatever term you want) parent of each revision. | 12:58 |
| fullermd | And declare that that revision is the one that, conceptually speaking, was "before me". | 12:58 |
| fullermd | Later parents (usually there would only be one, but you could octopus if you really wanted) are conceptually "stuff I grabbed from elsewhere". | 12:59 |
| fullermd | Linus likes to emphasize that merges are symmetrical; you merge two things together. That's true technically, but I (and bzr apparently) feel that socially they're asymmetric; you merge FROM somewhere else INTO your local thing. | 12:59 |
| fullermd | The mainline is a way of using that symmetry breaking to split up your history. So conceptually, unless you push/pull over something, the mainline is "what happened on this branch", and the right-side descents are "things I got from elsewhere". | 13:00 |
| fullermd | That means that, for instance, the revision before the head on the mainline (revno -2) is what was the head before your last commit. | 13:00 |
| fullermd | Whereas if you act in a way that doesn't preserve a mainline (like fast-forward merges, which most other systems default to always doing), you can't actually say "what was this before?" | 13:01 |
| fullermd | This is especially useful on a 'trunk' type branch, because it may be very useful to be able to look back and say "Hey, what was trunk like last week?" | 13:01 |
| davidstrauss | fullermd: Is there a concrete example of this behavior I can work through myself? | 13:02 |
| fullermd | With something like git, it's impossible to say deterministically (unless you tagged it), because there could be 5 or 6 branches of the history that existed independantly then. | 13:02 |
| fullermd | Sure, look at the history of bzr.dev. | 13:02 |
| fullermd | This exhibits another emergant property of the mainline, which is the 'rollup' capability for offside work. | 13:03 |
| fullermd | If I look at the --short log output for bzr.dev (which doesn't include non-mainline revisions), I see that the last commit was vila fixing some redirection bugs. The one before that was him messing with log formatting. Before that was Marius fixing some dotted revno stuff, then Solaris compilation fixes, cleaning debug code, adding another build target... and on and on. | 13:04 |
| fullermd | So in a way, I see the 'rollup' of what the conceptual bits that were done were. | 13:04 |
| davidstrauss | fullermd: By "rollup," do you mean a revision that encompasses several others? | 13:05 |
| fullermd | If I need to delve into the defailts of "what were the steps in changing that log format", I can walk down that line of history. But in a high-level view, I don't care; I want to know the bigger conceptual "things that were done" to the project. | 13:05 |
| davidstrauss | ok | 13:05 |
| fullermd | Sort of. In log [--long, or any formatter that shows merge revs] they look that way. | 13:05 |
| fullermd | In a strict sense, the history is no different than in git or any other ancestry-based VCS; it's all a DAG, and no revision is 'a subpart of' any other really. | 13:06 |
| davidstrauss | understood | 13:06 |
| fullermd | But the output uses the mainline to create a visual fiction that it's like that. | 13:06 |
| davidstrauss | fullermd: Will I see this behavior even if people push into the mainline? | 13:06 |
| fullermd | If you work in a way that preserves the mainline, and treats each commit to it as an individual unit (merge this feature, write that feature, etc), the log just walking down the mainline gives you a very neat view of the history. | 13:06 |
| fullermd | Pushing over the trunk can change the mainline, since the left-hand path is now different. | 13:07 |
| fullermd | That could mean that, say, the last 10 commits that were on mainline, are now "off to the right" of the last merge, and the new last 8 or 15 commits on mainline were details of implementing that last feature landed. | 13:08 |
| fullermd | If the heads of two branches are different, their mainlines will be different. If they're related branches, the mainline will usually be the same up to a point, but you'd have to examine a particular case to see where that is. | 13:09 |
| fullermd | For instance, my copy of bzr.dev and the "real" bzr.dev have different heads right now (I'm a revision behind; haven't sync'd since yesterday) | 13:09 |
| fullermd | So our revnos are the same up to 3904, but it's got a 3905. So, I have sorta an "earlier version" of it. | 13:10 |
| davidstrauss | fullermd: So, next week I'll be setting up Bazaar and training all the Drupal core developers on using it for the sprint. I'd like to have a clean mainline that exhibits the nice history you've mentioned. It looks like my choices for appending to that history are (1) commits from checkouts and (2) merges into the mainline. | 13:10 |
| davidstrauss | What workflow do you use for your working copy(ies) of bzr.dev? | 13:10 |
| fullermd | (2) is what you'd need, yes. (1) is IMO the simplest way of doing so. | 13:11 |
| fullermd | Well, I don't really work on bzr; I have bzr.dev around because it's the bzr I use day to do. In my work, we work with a shared trunk which all the devs checkout. | 13:11 |
| davidstrauss | fullermd: Do you use local commits at work? | 13:11 |
| fullermd | Trivial stuff is often just done directly on trunk, CVS style. More involved stuff happens in separate branches (most commonly dev-local, with the sort of work we do, but occasionally shared) | 13:11 |
| fullermd | I don't, no. If I'm working on trunk, I'm connected. | 13:12 |
| fullermd | And if I run 'commit' on trunk, it's because whatever I'm committing is ready to go out into the world. | 13:12 |
| LarstiQ | davidstrauss: I either work directly on trunk if it's small, or in a different branch if it's bigger, and merge it into trunk when ready. | 13:12 |
| davidstrauss | fullermd: Do you maintain a checkout and a branch, typically? | 13:12 |
| fullermd | Yah. Or several branches. | 13:13 |
| davidstrauss | LarstiQ: How do you merge into trunk? Do you directly got onto trunk and run "bzr merge"? | 13:13 |
| LarstiQ | davidstrauss: yup, with the branch I've been working in as an argument | 13:13 |
| davidstrauss | LarstiQ: Or do you keep a checkout of trunk to merge into? | 13:13 |
| LarstiQ | oh | 13:13 |
| fullermd | Actually, because of details of the environment, I generally have one branch that gets pull'd over and re-used, instead of recreated from scratch, for a lot of things. But I make specific branches sometimes too. | 13:13 |
| LarstiQ | I didn't understand 'directly' correctly | 13:14 |
| davidstrauss | For most projects I manage, logging into the Bazaar mainline server and running merge is a non-starter. | 13:14 |
| LarstiQ | davidstrauss: I never work directly on the remote trunk that lives on the central server. | 13:14 |
| LarstiQ | right | 13:14 |
| LarstiQ | davidstrauss: so, I cd to my local branch of trunk, and run merge | 13:15 |
| davidstrauss | It looks like "checkouts" are best treated as remote access points to do stuff directly on trunk. | 13:15 |
| fullermd | Nor I. The central 'trunk' doesn't even have a working tree. | 13:15 |
| * LarstiQ nods at fullermd | 13:15 | |
| fullermd | Yah. There's pretty much two ways to do it. | 13:15 |
| davidstrauss | fullermd: Same here. No working trees on trunk | 13:15 |
| LarstiQ | davidstrauss: depending on the project, my local copy of trunk is a checkout or a branch | 13:15 |
| fullermd | (1) have a 'branch' of trunk. When you want to land something, pull to update, merge your stuff, then push. Or, (2) have a checkout, update merge commit. | 13:16 |
| fullermd | They're roughly the same thing, but (2) is usually simpler. | 13:16 |
| davidstrauss | fullermd: Will (1) preserve a nice history on the mainline? | 13:16 |
| LarstiQ | davidstrauss: when a branch, I need to push after committing. If someone else than has committed something to the remote trunk, I need to do more work to get caught up, a potentially neverending cycle with race conditions. That is what a checkout makes easier. | 13:16 |
| fullermd | Yeah, they have the same end result. But the checkout automates staying in sync, making sure you're up-to-date, etc. | 13:16 |
| LarstiQ | davidstrauss: yes | 13:16 |
| fullermd | push won't push if you're out of sync. Strictly speaking, the remote head rev has to be in your history, or push will error. | 13:17 |
| davidstrauss | Doesn't pull refuse to run if you've diverged? | 13:17 |
| * LarstiQ would go for (1) if there is little chance of the remote trunk changing under your feet AND the overhead of a checkout is bothering you. | 13:17 | |
| LarstiQ | davidstrauss: yes | 13:17 |
| fullermd | Right. But in this case, you'd intentionally never diverge the trunk branch. | 13:17 |
| davidstrauss | So when you say "merge" into the branch of trunk, you mean from another branch that has the changes? | 13:18 |
| fullermd | (so if that priming 'pull' failed, something went wonky somewhere) | 13:18 |
| LarstiQ | davidstrauss: yes | 13:19 |
| fullermd | Yah. cd foo ; hack commit hack commit hack commit ; cd ../trunk ; bzr up ; bzr merge ../foo ; bzr ci | 13:19 |
| davidstrauss | fullermd: that's with a checkout | 13:19 |
| davidstrauss | right? | 13:19 |
| fullermd | Aside from the workflow stuff, I find it convenient having an up to date copy of trunk around anyway, for reference. | 13:19 |
| fullermd | Yah. With an independant branch of turnk, those last 3 steps would turn into "bzr pull ; bzr merge ../foo ; bzr ci ; bzr push" | 13:20 |
| LarstiQ | davidstrauss: for a branch it would be : cd foo; hack commit hack commit hack commit; cd ../trunk; bzr pull; bzr merge ../foo; bzr ci; bzr push | 13:20 |
| fullermd | Checkout saves you a step, and makes things easier if trunk happens to move while you're doing it. | 13:20 |
| LarstiQ | and beaten by fullermd, again :) | 13:20 |
| * fullermd steals LarstiQ's typing speed. | 13:20 | |
| fullermd | Since with a branch, if that last pull fails because trunk moved, you have to undo all the work, pull again, re-do the merge, etc. With a checkout, you can just 'update' and it will take care of merging your changes on top of the new head. | 13:21 |
| fullermd | (which may conflict, to be sure, and you may find it easier to revert and re-do the merge than to fix them, but usually IME it doesn't) | 13:21 |
| davidstrauss | yeah, i think i'll use the checkouts as the gateways to the mainline | 13:22 |
| * LarstiQ nods | 13:22 | |
| fullermd | And remember too how I scorn the Distributed Creed, and work on trunk a lot too ;) | 13:22 |
| LarstiQ | davidstrauss: I think that is good practice indeed. | 13:22 |
| fullermd | Probably the majority (by number, though not by time) of the changes I make are small enough that they belong in 1 commit anyway, so I just do those straight on trunk. | 13:22 |
| davidstrauss | As a side note, this isn't terribly documented on the Bazaar site | 13:23 |
| davidstrauss | Rather, I find the workflows document rather vague and poor | 13:23 |
| fullermd | So for those, the workflow is exactly as if I were still using CVS; make the change, commit, done. | 13:23 |
| davidstrauss | fullermd: And that's something I really like about Bazaar: the zero learning curve of just doing what you did with SVN | 13:24 |
| fullermd | Yeah. That workflow hung around for 20 years because for a lot of things, it works fine. | 13:24 |
| davidstrauss | It makes it easy for me to force bzr on dev teams and then evolve use of the powerful distributed features | 13:24 |
| davidstrauss | gradually | 13:25 |
| * fullermd nods. | 13:25 | |
| davidstrauss | With the Drupal dev team, we're taking CVS users in many cases | 13:25 |
| fullermd | You can move a whole team from SVN over to bzr, and not disturb anybody's workflow. Heck, everybody else can keep just working on trunk forever, but you still get to use branches. | 13:25 |
| davidstrauss | talking* | 13:25 |
| davidstrauss | exactly :-) | 13:25 |
| LarstiQ | there are some small glitches like svn copy, but in general, yes. | 13:26 |
| davidstrauss | And svn add vs. bzr add | 13:26 |
| davidstrauss | and the branch centricity of bzr versus current working directory and below for svn | 13:26 |
| davidstrauss | I've actually used bzr quite a bit at this point. I'm in here to become more of an expert because I know I'll get grilled next week for all of this. | 13:27 |
| davidstrauss | We're flying in people from around the world for this. I'm expected to know everything about the VCS I decided on. | 13:28 |
| LarstiQ | aah | 13:29 |
| LarstiQ | when does this all start? | 13:29 |
| davidstrauss | Monday | 13:29 |
| LarstiQ | ok | 13:29 |
| davidstrauss | Worst case was going to be falling back on just checkouts | 13:29 |
| davidstrauss | which would put us exactly where we would have been with SVN, anyway | 13:30 |
| LarstiQ | which will then get you the question, "why switch if it is the same?" | 13:30 |
| fullermd | I like to use profanity in answer to that :) | 13:31 |
| LarstiQ | davidstrauss: I'm going out for shopping now, but I'm interested in talking more about this if that's ok with you. | 13:31 |
| davidstrauss | LarstiQ: I maintain a bzr branch that tracks CVS HEAD. Even if we branch from that and then do everything checkout-style, we still save time. | 13:31 |
| davidstrauss | LarstiQ: Because then I don't have to set up Subversion with a vendor branch and a clone of my HEAD-trackign scheme. | 13:32 |
| davidstrauss | LarstiQ: bye | 13:32 |
| davidstrauss | Also, bzr is generally easier to use than svn. I hate svn's property-based ignore scheme. | 13:33 |
| davidstrauss | And my inability to use it is why you'll find an old checkin of mine for MediaWiki that includes a password file (albeit, a development one that would be useless outside the firewall). | 13:34 |
| davidstrauss | How is this possible when using shared branch storage? "In commercial environments, different teams might have their access controlled to various branches (e.g. development vs QA vs maintenance) on a server but, once again, these branches can be using a shared repository for efficient storage. It's also clearly beneficial for hosting sites like Launchpad." | 13:58 |
| davidstrauss | Wouldn't all of the teams need access to the shared storage location? | 13:59 |
| Peng_ | davidstrauss: Yeah, you're right. I guess you could create repos per-team, and the recent stacking feature will really help. | 14:03 |
| davidstrauss | Peng_: I pulled the quote from the BzrVsGit page. It seems like shared storage makes it distinctly less possible to separate out permissions. | 14:04 |
| * Peng_ doesn't read the Vs pages. | 14:05 | |
| Peng_ | davidstrauss: Yeah, it does. | 14:05 |
| fullermd | It's easy. First, we eliminate the VFS layer from the SS... | 14:05 |
| Peng_ | davidstrauss: Like I said, stacking really helps there. | 14:05 |
| davidstrauss | fullermd: I can't tell if you're being sarcastic | 14:06 |
| Peng_ | fullermd is right too. It would be possible to make the smart server support permissions, though not easy. | 14:06 |
| Peng_ | davidstrauss: Taking out the VFS would be a ton of work, but is desired for the future anyway, since it's often bad for performance. | 14:07 |
| davidstrauss | ok | 14:07 |
| davidstrauss | Also, it seems like full branch > history horizon branch (not existent yet) > stacked branch in terms of space requirements and local capabilities. | 14:07 |
| davidstrauss | But I've never seen them described as such | 14:08 |
| fullermd | Oh, not sarcastic per se. Sardonic maybe. | 14:17 |
| rocky | jelmer: another svn branch checkout failing... with bzr 1.10 and bzr-svn 0.5 branch | 14:32 |
| rocky | :( | 14:32 |
| rocky | jelmer: http://cluebin.appspot.com/pasted/3611 | 14:35 |
| rocky | jelmer: and http://cluebin.appspot.com/pasted/4002 for the bzr.log output | 14:38 |
| mkanat | Let's say I had a repo where the clock was wrong for a really long time, and now I have thousands of commits whose time is off by X hours exactly--can I fix that? | 14:42 |
| mkanat | s/repo/branch/ | 14:43 |
| davidstrauss | mkanat: The general response I hear is that revision history data is immutable. | 14:53 |
| mkanat | davidstrauss: That's what I've heard as well, I was just wondering if there was any way to safely muck about with it. | 14:53 |
| mkanat | Anyhow, I'm off to sleep, I'll ask again some time later. | 14:54 |
| davidstrauss | mkanat: I'm guessing the answer is no *safe* way | 14:54 |
| davidstrauss | mkanat: goodnight | 14:54 |
| mkanat | davidstrauss: I'd guess that too. :-) | 14:54 |
| mkanat | Night1 | 14:54 |
| mkanat | *Night! | 14:54 |
| Peng_ | The time is used in the revision IDs themselves too, not that it really matters. | 14:58 |
| lifeless | 0 | 15:24 |
| davidstrauss | lifeless: ? | 15:31 |
| lifeless | mistype | 15:31 |
| GaryvdM | Hi - What do I do if I get this error: http://pastebin.com/mf46f9ef | 16:09 |
| GaryvdM | BzrCheckError: Internal check failed: Newly created pack file <bzrlib.repofmt.pack_repo.NewPack object at 0x01548CD0> has delta references to items not in its repository: | 16:09 |
| davidstrauss | GaryvdM: You have a corrupted repository. | 16:10 |
| GaryvdM | Where I am pushing from or where I am pushing to? | 16:11 |
| davidstrauss | GaryvdM: what do you get from "bzr check" | 16:11 |
| GaryvdM | Ok - I'm runing check on my local branch | 16:11 |
| davidstrauss | GaryvdM: though it's likely the issue is with the external repository | 16:12 |
| GaryvdM | http://pastebin.com/m7264518f | 16:13 |
| GaryvdM | Seams ok | 16:13 |
| davidstrauss | GaryvdM: What client version are you using? | 16:13 |
| GaryvdM | Bazaar (bzr) 1.11dev | 16:14 |
| GaryvdM | from bzr checkout C:/Documents and Settings/Gary/My Documents/bzr/bzr.dev | 16:14 |
| GaryvdM | revision: 3904 | 16:14 |
| GaryvdM | revid: pqm@pqm.ubuntu.com-20081213000403-r1acnqhux25xhil1 | 16:14 |
| GaryvdM | branch nick: bzr.dev | 16:14 |
| davidstrauss | GaryvdM: stacked branch? | 16:14 |
| GaryvdM | Yes | 16:14 |
| davidstrauss | GaryvdM: https://bugs.edge.launchpad.net/bzr/+bug/302698 | 16:14 |
| ubottu | Launchpad bug 302698 in bzr ""BzrCheckError: Internal check failed: Newly created pack file <bzrlib.repofmt.pack_repo.NewPack object at 0x2e23f90> has delta references to items not in its repository:" on pushing a stacked branch" [High,Confirmed] | 16:14 |
| GaryvdM | Ok - thanks. I'm going to try an older version of bzr. | 16:16 |
| davidstrauss | GaryvdM: Also similar: https://bugs.launchpad.net/bzr/+bug/307146 | 16:17 |
| ubottu | Launchpad bug 307146 in bzr "Can't push svn clone to bzr" [Undecided,New] | 16:17 |
| davidstrauss | GaryvdM: you can also check the Launchpad branch remotely, I believe | 16:18 |
| GaryvdM | davidstrauss: I revert to bzr 1.10 - The problem still existed. I reverted to bzr 1.9 and I was able to push successfully. Later tonight I'll try work out at which revision this regression occurred. | 16:43 |
| mdmkolbe | Help my repository has gone haywire. I did some edits then a "bzr ci --local" (when off the network) and some more edits afterwords. Now back on the network, I try to do a "bzr ci" and it says it can't do that until I do a "bzr update". Now it has thrown up all sorts of text conflicts and a pending merge (what ever that means). I am the only person editing the source so I don't understand how conflicts could have appeared. How do I get back to a | 16:43 |
| LarstiQ | mdmkolbe: cut off at 'How do I get back to a' | 16:43 |
| LarstiQ | mdmkolbe: https://bugs.edge.launchpad.net/bzr/+bug/113809 | 16:44 |
| ubottu | Launchpad bug 113809 in bzr "update performs two merges" [High,Confirmed] | 16:44 |
| mdmkolbe | How do I get back to a sane state? (I have uncommited changes that I *don't* want to loose) | 16:44 |
| davidstrauss | LarstiQ: beat me to it | 16:44 |
| davidstrauss | mdmkolbe: The changes you generally want to keep will be in the .moved files | 16:44 |
| davidstrauss | mdmkolbe: checkout + local commit + uncommitted changes + update is currently a recipe for disaster | 16:45 |
| davidstrauss | mdmkolbe: The *.THIS.moved files likely have your uncommitted changes in them | 16:47 |
| davidstrauss | mdmkolbe: Is that the case? | 16:47 |
| * mdmkolbe looks | 16:47 | |
| davidstrauss | mdmkolbe: And the "pending merge" represents a local commit you did | 16:48 |
| mdmkolbe | davidstrauss: yes the THIS.moved files look right | 16:49 |
| davidstrauss | mdmkolbe: You'll want to copy the contents of the THIS.moved files into the conflicted files | 16:49 |
| davidstrauss | mdmkolbe: And then you can delete all the THIS, OTHER, BASE, and .moved files | 16:50 |
| davidstrauss | mdmkolbe: run bzr resolved | 16:50 |
| davidstrauss | mdmkolbe: and you should have a clean copy | 16:50 |
| mdmkolbe | davidstrauss: it looks like I have a conflicted directory and some sort of path conflict(?) | 16:50 |
| davidstrauss | mdmkolbe: the path conflicts are side-effects of the same thing | 16:50 |
| davidstrauss | mdmkolbe: bzr treats directories as versioned objects | 16:51 |
| davidstrauss | mdmkolbe: back up the conflict files, just in case they have anything useful in them | 16:52 |
| mdmkolbe | it is still listing "conflict adding file foo.BASE" | 16:54 |
| davidstrauss | mdmkolbe: in bzr status? | 16:54 |
| mdmkolbe | yes | 16:54 |
| davidstrauss | mdmkolbe: have you run "bzr resolve" | 16:54 |
| mdmkolbe | (also OTHER and THIS) | 16:54 |
| mdmkolbe | yes, it says "remainling conflicts:" then lists *base, other, this" | 16:55 |
| davidstrauss | mdmkolbe: and moved the conflict files where bzr can't see them? | 16:55 |
| mdmkolbe | I now have but on the first resolve I didn't | 16:55 |
| davidstrauss | mdmkolbe: you need to run resolve after removing the conflict files | 16:56 |
| davidstrauss | mdmkolbe: and you may need to "bzr resolve [file-it's-complaining-about]" explicitly | 16:56 |
| mdmkolbe | ah, that last part did it | 16:56 |
| davidstrauss | mdmkolbe: The only safe way to update is if you don't have a combination of uncommitted changes and local commits. | 16:57 |
| davidstrauss | mdmkolbe: I personally avoid local commits because of the problem you just encountered. | 16:58 |
| mdmkolbe | davidstrauss: what if I have multiple local commits. (i.e. instead of "ci --local" and "ci" do "ci --local" and "ci --local" "update) | 16:58 |
| davidstrauss | mdmkolbe: i believe multiple local commits is fine | 16:59 |
| davidstrauss | let me check | 16:59 |
| LarstiQ | if you have local commits, but no uncommitted changes, that should work afaik | 16:59 |
| mdmkolbe | davidstrauss: ok, so I've cleared all the conflicts, but bzr st still lists a "pending merge". Do I need to clear that? | 16:59 |
| LarstiQ | what could happen is that you have file.moved.moved.moved | 16:59 |
| davidstrauss | mdmkolbe: Just checked, and multiple local commits is OK. | 17:00 |
| LarstiQ | with multiple levels of conflict | 17:00 |
| davidstrauss | mdmkolbe: the pending merge is just your local commit | 17:00 |
| LarstiQ | in that case, you might need to bzr resolve file.moved.moved, not just 'file' itself | 17:00 |
| * LarstiQ hopes 113809 gets fixed soon | 17:01 | |
| mdmkolbe | davidstrauss: so ... do I do another local commit now and finish with an update? | 17:01 |
| davidstrauss | mdmkolbe: do you have uncommitted changes? | 17:01 |
| mdmkolbe | davidstrauss: yes | 17:01 |
| davidstrauss | mdmkolbe: then, yes, do a local commit and update | 17:01 |
| davidstrauss | mdmkolbe: and then you may commit | 17:02 |
| davidstrauss | (centrally) | 17:02 |
| mdmkolbe | davidstrauss: ok, I did "ci --local" and then "update". It complains about "conflict: can't delete <directoryname> because not empty" | 17:04 |
| davidstrauss | mdmkolbe: what directory? | 17:04 |
| mdmkolbe | src/unicode/ucd/properties | 17:04 |
| LarstiQ | that might be a valid conflict between your local revisions and the upstream? | 17:04 |
| mdmkolbe | LarstiQ: I am the only committer so I don't think so | 17:04 |
| davidstrauss | mdmkolbe: do you have local changes in that directory? | 17:05 |
| mdmkolbe | davidstrauss: yes | 17:05 |
| davidstrauss | mdmkolbe: i'd back up that directory, revert it, update, and re-integrate your changes | 17:05 |
| davidstrauss | sorry, back | 17:07 |
| LarstiQ | didn't miss anything | 17:08 |
| mdmkolbe | davidstrauss: I *think* it is now all back to normal. Is there a graphical tool for viewing revision history trees? (I'm currious what happened as a result.) | 17:10 |
| davidstrauss | mdmkolbe: It's not going to be visible in the tree. It happened due to a double merge. The craziness never got committed. | 17:11 |
| LarstiQ | mdmkolbe: qlog from qbzr and viz from bzr-gtk are nice tools, but I'm not sure that is what you are asking for | 17:12 |
| mdmkolbe | davidstrauss: but I see 16 then 16.1, 16.2,16.3 and finally 17 in the bzr log | 17:12 |
| davidstrauss | mdmkolbe: there will be at least your local commits | 17:12 |
| davidstrauss | mdmkolbe: i mean, you won't see the problem in the tree | 17:12 |
| LarstiQ | 16.1, 16.2 and 16.3 should be your local commits | 17:12 |
| mdmkolbe | ah, I think I see what you mean | 17:13 |
| mdmkolbe | Thank you *very* much for your help. | 17:14 |
| davidstrauss | :-) | 17:14 |
| mdmkolbe | (Though it baffles me that such a bug could exist (I would have thought a proper design would prevent it) and actually makes me wonder whether I can continue to trust bzr with my data.) | 17:16 |
| Peng_ | What bug? Local commits getting mangled? | 17:17 |
| mdmkolbe | Peng_: yes | 17:17 |
| Peng_ | Well, I trust bzr with my data, but I don't use checkouts. | 17:18 |
| davidstrauss | mdmkolbe: Just don't use local commits. I haven't encountered a similar problem elsewhere in Bazaar. | 17:21 |
| davidstrauss | mdmkolbe: There's a lot of debate about the future of local commits in Bazaar, anyway. | 17:21 |
| mdmkolbe | what if I am away from a network? | 17:21 |
| mdmkolbe | (that was the reason I used local commits in the first place) | 17:21 |
| davidstrauss | mdmkolbe: The best thing to do is checkout to your laptop and then branch from that. | 17:22 |
| davidstrauss | mdmkolbe: It's lightweight it you use shared branch storage. | 17:22 |
| davidstrauss | mdmkolbe: The workflow is then local branch --- merge ---> local checkout --- commit ---> central branch | 17:23 |
| davidstrauss | mdmkolbe: The local checkout is merely a gateway to the central branch | 17:23 |
| davidstrauss | mdmkolbe: Or you can always merge into the central branch | 17:23 |
| davidstrauss | mdmkolbe: Or push and pull | 17:23 |
| davidstrauss | mdmkolbe: Or just resolve to not mix local commits with uncommitted changes when you update. | 17:24 |
| davidstrauss | That last one is the easiest, but it's also the most likely to have you running into the problem again. | 17:24 |
| mdmkolbe | ok, well I guess I'll be remembering that for next time | 17:25 |
| davidstrauss | mdmkolbe: I'm currently pushing for updates to be denied if you have both local commits and uncommitted changes | 17:27 |
| davidstrauss | mdmkolbe: http://www.nabble.com/Re%3A-Recommended-use-of-Bazaar-for-single-committer-multiple-machine-projects--p20989853.html | 17:28 |
| mdmkolbe | davidstrauss: I think that should be done at a bare minimum. What I would have expected what that a check out just means that "ci" is really "ci --local;push" or some such (maybe with a rolback of the "ci --local" if the "push" fails). then this problem shouldn't even be able to happen | 17:30 |
| davidstrauss | mdmkolbe: ci --local;push does something quite different | 17:31 |
| davidstrauss | mdmkolbe: There's actually no obvious solution for merging into a checkout with both local commits and uncommitted changes. | 17:35 |
| mdmkolbe | davidstrauss: hmm, this may explain why both darcs and git require local changes to be explicitly staged before being pushed up stream. I guess I assumed bzr was doing the same just providing a single command. | 17:38 |
| davidstrauss | mdmkolbe: yes | 17:40 |
| davidstrauss | Where is the code for the update command in the Bazaar source? | 17:40 |
| GaryvdM | bzrlib\bulitins.py line 1121 | 17:42 |
| davidstrauss | Thanks | 17:43 |
| davidstrauss | GaryvdM: How easy would it be to change it to detect either uncommitted changes or local commits? | 17:43 |
| Peng_ | Probably not very difficult. | 17:44 |
| davidstrauss | That's what I thought | 17:44 |
| davidstrauss | If we can at least get that into trunk, we can avoid the horrors mdmkolbe just experienced. | 17:45 |
| mdmkolbe | I should note that this sort of check to stop bad behaviour has precident. IIRC there are some situations where SVN will refuse to do an operation. It gives an infomative message about why it wont do it and what you should do in order to make it happy. It also tells you that if you really do want to do it any way you can pass a "--force" option. | 17:47 |
| mdmkolbe | As a user seeing that message is mildly anoying (sometimes I think "if svn is telling me what I need to do to make it happy, then why doesn't it go ahead and do it itselft"). but when using it I also realize that having your VCS be too conservative is better than having it be too loose | 17:49 |
| davidstrauss | My Python is rather rusty, but I should be able to just pull some code over from the status command into the update one to do the necessary check. | 17:53 |
| davidstrauss | How can you detect the presence of local commits? | 17:56 |
| LarstiQ | davidstrauss: presumably this is at the point where you are running update, right? | 17:56 |
| davidstrauss | LarstiQ: yes | 17:57 |
| LarstiQ | In which case you should know the tip of the master branch, and your own tip. | 17:57 |
| davidstrauss | Yes, I see that | 17:57 |
| LarstiQ | if there is divergence, there are local commits. | 17:57 |
| LarstiQ | There might be nice api for this, that I do not know. | 17:57 |
| davidstrauss | I assume "master is None" means it's not a checkout? | 17:58 |
| LarstiQ | davidstrauss: I haven't looked at that code, but I'd guess that's correct. | 17:58 |
| LarstiQ | AmanicA: ooh, _you're_ Marius Kruger! | 18:18 |
| davidstrauss | Is there a command to have Bazaar list local commits? | 18:24 |
| GaryvdM | qlog | 18:25 |
| GaryvdM | I don't know about the command line | 18:25 |
| davidstrauss | qlog? | 18:26 |
| Odd_Bloke | davidstrauss: "bzr missing --mine" | 18:26 |
| davidstrauss | Odd_Bloke: nope | 18:27 |
| davidstrauss | Odd_Bloke: maybe "bzr missing --mine :bound" | 18:27 |
| Odd_Bloke | davidstrauss: What do you mean by 'local commits'? | 18:27 |
| davidstrauss | Odd_Bloke: to a checkout | 18:27 |
| Odd_Bloke | davidstrauss: Have you tried "bzr missing --mine :bound"? | 18:28 |
| LarstiQ | didn't he just say that? :) | 18:28 |
| LarstiQ | Odd_Bloke: davidstrauss is working on bug 113809 | 18:29 |
| LarstiQ | Odd_Bloke: heya, btw :) | 18:29 |
| ubottu | Launchpad bug 113809 in bzr "update performs two merges" [High,Confirmed] https://launchpad.net/bugs/113809 | 18:29 |
| Odd_Bloke | LarstiQ: No, he didn't. :) | 18:29 |
| davidstrauss | I'm at the point where I need to test for the (1) uncommitted changes and (2) local commits | 18:29 |
| Odd_Bloke | LarstiQ: Hi. :D | 18:29 |
| bialix | AmanicA: ping | 18:34 |
| davidstrauss | Local commit testing: check | 18:38 |
| davidstrauss | Now to look for uncommitted changes | 18:38 |
| aantn | hello | 18:44 |
| aantn | what's the best way to remove the last commit from a remote branch | 18:45 |
| aantn | (If I use bzr uncommit, it'll only remove it from the local branch's history) | 18:45 |
| aantn | someone accidentally committed personal information and I'd like to remove all traces of the commit | 18:46 |
| davidstrauss | aantn: uncommit won't do that | 18:47 |
| bialix | push --overwrite | 18:47 |
| aantn | bialix: thanks | 18:47 |
| bialix | np | 18:47 |
| davidstrauss | I said "won't do that" because uncommit doesn't destroy the data | 18:48 |
| aantn | davidstrauss: is there a way to do that, then? | 18:49 |
| davidstrauss | aantn: not to my knowledge | 18:49 |
| bialix | removing the branch completely and push it again | 18:49 |
| bialix | there is no simple way for nuking uncommitted revisions | 18:50 |
| davidstrauss | bialix: aantn would still have the ghost revision in the pushed data | 18:50 |
| bialix | no | 18:50 |
| bialix | it's not ghost revision | 18:50 |
| davidstrauss | even when you uncommit? | 18:50 |
| bialix | there is (was) plugin named remove-revisions to do this job | 18:51 |
| bialix | when you uncommit your revision still in the repository | 18:51 |
| bialix | when you do push, uncommitted revisions will not propagate | 18:51 |
| bialix | or pull or branch, does not matter | 18:52 |
| aantn | bialix: would uncommitting be sufficient then? | 18:52 |
| bialix | this is main reason why branching in bzr much slower operation than clone in hg or git | 18:52 |
| davidstrauss | I see | 18:52 |
| bialix | aantn: it depends if you have shell access to your server | 18:53 |
| aantn | bialix: it's a launchpad branch | 18:53 |
| bialix | oh | 18:53 |
| aantn | I've already notified the person and they should have changed the password by now anyway | 18:54 |
| LarstiQ | aantn: uncommit and push --overwerite are sufficient for no one being able to get the information by branching | 18:54 |
| bialix | do local uncommit and then push --overwrite to lp | 18:54 |
| aantn | bialix, LarstiQ: thanks; already done | 18:55 |
| LarstiQ | aantn: and ask one of the lp admins to clean the repository | 18:55 |
| aantn | LarstiQ: ok; is there anyone in here who can help? | 18:55 |
| LarstiQ | aantn: https://answers.launchpad.net/launchpad/+addquestion | 18:55 |
| bialix | AmanicA: if you'll read this later tonight: I'm going offline, check your mail | 18:55 |
| bpierre | hi | 19:07 |
| bpierre | do you use the launchpad interface for merge requests? | 19:07 |
| davidstrauss | Done with my patch :-) | 19:07 |
| davidstrauss | What do you guys think? http://pastebin.com/m5586168e | 19:08 |
| davidstrauss | How do you use bzr send to create a merge directive but not send an email? | 19:13 |
| LarstiQ | davidstrauss: bzr send -o <file> | 19:14 |
| bpierre | davidstrauss: use -o file | 19:14 |
| davidstrauss | not sure how i missed that in bzr help send | 19:14 |
| davidstrauss | More importantly, what do you think of the patch? | 19:15 |
| LarstiQ | davidstrauss: you should probably use `dir` instead of u"." | 19:17 |
| davidstrauss | LarstiQ: Like this? "local_branch = Branch.open_containing(dir)[0]" | 19:18 |
| LarstiQ | davidstrauss: yup, assuming dir is still the same as at the top of the cmd_update run | 19:18 |
| LarstiQ | davidstrauss: other than that, looks good. | 19:18 |
| LarstiQ | davidstrauss: you might want to include a NEWS entry too | 19:18 |
| davidstrauss | Is there a special Launchpad way for me to submit merge directives? | 19:24 |
| davidstrauss | LarstiQ: And it has a NEWS entry, too. | 19:25 |
| LarstiQ | that I do not know. But the Bazaar project primarily uses bundle buggy wathcing the mailing list for patch proposals, not launchpad. | 19:25 |
| davidstrauss | then I'll email to that | 19:25 |
| bpierre | ah, answered my question | 19:26 |
| LarstiQ | davidstrauss: after which you can track it at http://bundlebuggy.aaronbentley.com/ | 19:26 |
| cammoblammo | I'm running bzr 1.5 on Debian. I mainly use it for syncing a heap of text files between a few machines, although I also follow a couple of software projects with it as well. Is there anything to be gained by compiling and installing 1.10? | 19:27 |
| davidstrauss | LarstiQ: And emailed. | 19:28 |
| davidstrauss | I do email to bundlebuggy@aaronbentley.com right? | 19:31 |
| LarstiQ | eh, no :) | 19:32 |
| LarstiQ | davidstrauss: sorry, I should have made that more clear. | 19:32 |
| LarstiQ | davidstrauss: bundlebuggy monitors the regular bazaar mailing list | 19:32 |
| davidstrauss | So I email to bazaar@lists.canonical.com? | 19:33 |
| LarstiQ | davidstrauss: use a subject of [MERGE/RFC] warn the user when updating with both local commits and uncommited changes, or something like that | 19:34 |
| LarstiQ | davidstrauss: yes | 19:34 |
| LarstiQ | davidstrauss: more guidelines are listed in doc/developers/HACKING.txt, specifically 'Sending patches for review' in this case | 19:35 |
| davidstrauss | LarstiQ: thanks | 19:45 |
| LarstiQ | davidstrauss: it's in bundle buggy now too | 20:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!