| lifeless | back | 00:48 |
|---|---|---|
| grettke | Hi guys. I see 1.9 was just released. There is a RC1 build for Windows, think that should I hold off until the 1.9FINAL is distributed, or is RC1 good enough for now? | 01:03 |
| spiv | grettke: I don't think there are many changes in 1.9 vs. 1.9rc1, the rc1 build is probably ok. | 01:05 |
| spiv | That said, I'd expect the final build to be done pretty soon. | 01:05 |
| spiv | So if you're unsure, maybe just wait a day or tow. | 01:06 |
| spiv | "two", rather. | 01:06 |
| grettke | spiv: I see. Thanks. | 01:06 |
| lifeless | there was a regression in rc1 | 01:07 |
| lifeless | fixed in 1.9 | 01:07 |
| lifeless | I suggest waiting | 01:07 |
| fullermd | Gaah. There's no way to shut off color in shelve anymore? :( | 01:07 |
| grettke | lifeless: Good to know. Will do. | 01:07 |
| lifeless | fullermd: file bugs | 01:08 |
| * fullermd is so doing. | 01:08 | |
| lifeless | fullermd: I assume you're looking at the new shelve | 01:08 |
| fullermd | Yah. | 01:08 |
| grettke | What Bzr-web integration tool do you guys prefer: loggerhead or bzrweb? | 01:19 |
| lifeless | loggerhead | 01:19 |
| jelmer | hmm, upgade is recursive now? | 01:28 |
| lifeless | doggymenz: http://en.wikipedia.org/wiki/Comparison_of_revision_control_software | 02:00 |
| lifeless | bah | 02:00 |
| lifeless | http://en.wikipedia.org/wiki/Comparison_of_revision_control_software | 02:00 |
| lifeless | I love the comment "Not necessary since entire project is replicated locally" under 'web interfaces' for some scm's | 02:00 |
| lifeless | epic fail | 02:00 |
| fullermd | Is that sorta like "branch support not necessary 'cuz we have a cheap copy"? :p | 02:02 |
| poolie | "merge support not necessary because branching is impossible" | 02:06 |
| poolie | :-) | 02:06 |
| lifeless | ah, svn? | 02:08 |
| poolie | actually rcs | 02:15 |
| lifeless | didn't rcs have branches? | 02:24 |
| lifeless | I'm sure it did | 02:24 |
| jonoxer | Is there any way to enforce an arbitrary policy on encountering a conflict, such as automatically picking whatever is the latest file regardless of what is in them? | 02:30 |
| jonoxer | The problem is we have a bunch of binary files being generated in working copies, and they get committed (they need to be) but them always conflict | 02:31 |
| jdong | ooh add me to the wishlist of an evil-downstream-plugin too! | 02:31 |
| jonoxer | s/them/then | 02:32 |
| jonoxer | What I'd like to do is have a rule like "when merging, if any file has an extension of .blah then use whichever is most recent" | 02:32 |
| jonoxer | As an example, a typical use-case might be images in a source tree. They may be replaced from time to time, but bzr then sees them conflicting | 02:34 |
| lifeless | jonoxer: yes; write a merge plugin. I *think* the infrastructure is sufficient unto the task | 02:35 |
| lifeless | jonoxer: note that bzr should only see a conflict when there are concurrent changes in two branches to one file - and when that happens 'most recent' is not defined | 02:36 |
| lifeless | jonoxer: unless you trust the clock on your developers machines | 02:36 |
| jonoxer | lifeless: Ah, I see, so in a situation where the binary has changed in *both* branches then it will conflict. That makes sense | 02:36 |
| lifeless | jonoxer: and if its only changed in one branch it won't conflict ever (unless there is a local uncommitted change, but thats really a psuedo-branch anyhow) | 02:37 |
| lifeless | jonoxer: are you encountering conflicts - is this a concrete issue, or a hypothetical? | 02:37 |
| jonoxer | lifeless: concrete, but it's partly because of the way we're using it that I'm sure you didn't think about when designing it... | 02:38 |
| lifeless | jonoxer: guaranteed. I was just saying to poolie last night that users are insane :) | 02:38 |
| jonoxer | In this scenario we have a bunch of developers working on Flex web apps, which have source trees of .mxml and .as files but each time the IDE builds the project it compiles .swf files in the tree. These are necessary for the app to run, but are somewhat transient: they can simply be regenerated if necessary, but the situation we're trying to avoid is having to regenerate every single one every time, hence them being committed | 02:40 |
| lifeless | jonoxer: ah right, but the ide is insane and does it anyhow :P | 02:40 |
| lifeless | jonoxer: and I bet it puts a datestamp in the file, so identical inputs -> different outputs | 02:40 |
| jonoxer | lifeless: yep, I'm pretty sure that's part of the problem | 02:41 |
| lifeless | jonoxer: right, with auto-creation and spurious changes you'll get spurious conflicts | 02:42 |
| lifeless | jonoxer: now, the question is, can you programmatically tell these two cases apart: | 02:42 |
| jonoxer | lifeless: I've tried suggesting to the devs that we should just exclude all the .swf files from being committed, but was met with a hail of nerf balls and staplers and lunchboxes | 02:42 |
| lifeless | a) I added a file and the .swf has to change | 02:42 |
| lifeless | b) a spurious change has occured | 02:42 |
| jonoxer | lifeless: in this case it should be enough to simply tell which has the later creation date, and pick that one | 02:43 |
| lifeless | or to rephrase - what is the impact on correctness in your app if your auto-resolved chooses the wrong .swf (or if in fact neither .swf is correct because both branches changed things that require it to be recreated) | 02:44 |
| jonoxer | lifeless: not much at all. Worst case is to delete the swf and tell the IDE to regenerate it | 02:44 |
| lifeless | jonoxer: back to the a/b question, concurrency is hard - let me expand the scenario: | 02:44 |
| lifeless | a) I add a file and the .swf has to change, monday 4pm | 02:44 |
| lifeless | b) you just regened and committed before you went home, monday 5pm | 02:45 |
| jonoxer | lifeless: yes, I see: in that case the latest .swf won't actually be the one required. I don't think we can avoid that situation entirely | 02:47 |
| jonoxer | lifeless: I don't think it matters a huge amount, though. | 02:48 |
| jonoxer | lifeless: It just needs to have *a* copy of the binary, and if it's not quite the latest one that's generally OK | 02:48 |
| === timchen119 is now known as nasloc__ | ||
| jonoxer | The problem ATM is that the app ends up broken because neither version of the .swf ends up in place | 02:49 |
| jonoxer | lifeless: hmm, maybe I could make it work in a brute-force way using a script that can be run after a merge, and it finds conflicting .swf files and makes an arbitrary decision and resolves the conflict automatically | 02:52 |
| lifeless | jonoxer: thats likely the easiest way; as I say though there is a merge plugin capability | 02:53 |
| jonoxer | Wouldn't always pick the best one (as you pointed out about concurrency) but it would make the app "work" | 02:53 |
| lifeless | jonoxer: should be reasonably straight forward to do a merge that looks for these files (and if not, file a bug :)) | 02:53 |
| jonoxer | lifeless: thanks for the pointers. I'll have a look at the merge plugin interface and see if I can understand it | 02:54 |
| rocky | i'm trying to understand... how is it possible that i create a local init folder with old 0.92 repo format and then i push it to a server that is using a shared repo of --1.9 that the new branch that i just pushed ends up with 1.9 repo format on the server? | 03:48 |
| rocky | i'm having a hard time wrapping my head around that | 03:48 |
| rocky | it seems sooooo different from the way the svn server stuff works which i think is part of the reason i'm having difficulty grasping it | 03:49 |
| lifeless | rocky: 'server is using a shared repo of --1.9' | 03:54 |
| lifeless | rocky: so the branch created in the repo uses the repo | 03:54 |
| rocky | so this is really possible because the remote branch and the local branch are actually two separate branches with their own repos that just happen to keep getting synced up? | 03:56 |
| grettke | Hi guys. What is the approach for backing up repos? I've got a shared repo that has all of my mainline branches in it. Is it simply a matter of doing a file system backup? | 04:01 |
| lifeless | rocky: uhm | 04:01 |
| rocky | lifeless: you can probably tell by my questioning that i'm simply "not getting it" | 04:02 |
| lifeless | rocky: actually you got it fine I think | 04:03 |
| lifeless | rocky: I'm on a phone call, and I typed what I was saying | 04:03 |
| rocky | lol ok ;) | 04:03 |
| grettke | that wasn't the correct terminology... | 04:04 |
| thumper | lifeless: are you in brisbane? | 04:04 |
| lifeless | thumper: no | 04:05 |
| rocky | i think i'm going to write a very minimalistic bzr http server that has r/w access and just uses the standard wsgi/http transport thing from bzr plus some common authentication/authorization middleware | 04:08 |
| lifeless | rocky: should just be a case of enabling apache auth | 04:17 |
| lifeless | rocky: the web server is already wsgi; and supports r/w access | 04:18 |
| rocky | right | 04:18 |
| kumi | which one should be faster: bzr+http:// or http:// ? | 04:19 |
| lifeless | kumi: http:// at the moment, but we're working on bzr+http | 04:20 |
| kumi | Cool | 04:21 |
| rocky | lifeless: well ... part of what is missing say compared to svn is authz support ... giving people access to just certain branches... that's currently not possible with just apache+bzr/http | 04:22 |
| lifeless | rocky: true; otoh you can setup multiple repositories much more easily, which is likely why there is not that much pressure to address this | 04:22 |
| kumi | I'd love bzr serve to have some basic auth capability like svnserve | 04:22 |
| lifeless | there's some stuff been happening towards that, as wrapper scripts | 04:23 |
| lifeless | thumper: I'm not in brisbane - too under the weather | 04:23 |
| kumi | Really? Do you have a link? | 04:23 |
| thumper | lifeless: get well dude | 04:23 |
| lifeless | kumi: it was on the list in the last week | 04:23 |
| rocky | lifeless: i'm not sure what point your last comment was making, how is setting up multiple repos make there be less pressure? | 04:23 |
| kumi | thanks | 04:24 |
| lifeless | rocky: setup a repo per group of access rights | 04:24 |
| rocky | lifeless: oh... using different <Location> directives in apache conf with different auth settings you mean? | 04:24 |
| lifeless | rocky: that, and additional physical repositories | 04:24 |
| lifeless | rocky: its a distributed database, there is no need for all branches to be in the same repository | 04:25 |
| rocky | well ... you see the problem is that now that i'm finally grokking some of the other stuff... knowing how to piece some of that stuff together is a little more natural ... but as i was trying to wrap my head around this essentially what i wanted was authorization control using "bzr serve" like kumi just asked for | 04:26 |
| rocky | so the only way any of this stuff makes sense is if you have a good understanding of how bzr repos/branches work and you don't try to compare it to svn | 04:26 |
| lifeless | sadly, that is true. svn really is a very different beast for a system administrator | 04:27 |
| rocky | perhaps bzr needs a "recipe" site where there are little recipes for admins on how to setup apache + bzr + auth and stuff like that | 04:27 |
| rocky | the fact is... most of the admins i know would rather send stuff like this through http instead of using ssh/sftp | 04:27 |
| kumi | lifeless: I'm afraid I can't find the wrapper script discussion in the mailing list @ https://lists.ubuntu.com/archives/bazaar/2008q4/thread.html | 04:31 |
| rocky | lifeless & kumi: this bzr http server i'm talking about is essentially what kumi is asking for i think | 04:34 |
| kumi | I'm actually looking for a way to run bzr serve as standalone or inetd (like svnserve) | 04:36 |
| kumi | ...with some kind of authentication | 04:37 |
| rocky | right, that's what i'm talking about writing | 04:38 |
| kumi | right now I have fwknopd protecting the port, but that's a hack | 04:38 |
| lifeless | kumi: so why are you using bzr: and not either bzr+http or bzr+ssh ? | 04:51 |
| rocky | is it possible to write a bzr plugin that exposes the plugin info using an egg entry point instead of having to put your plugin into one of the special bzrlib/plugins places? | 04:53 |
| lifeless | rocky: there isn't any code in bzr to handle eggs | 04:55 |
| lifeless | rocky: if eggs can honour the normal python behaviour of modules and packages it will just work | 04:55 |
| lifeless | rocky: if they can't, it won't, unless someone contributes a discovery mechanism for eggs to bzr itself | 04:55 |
| rocky | i think a discovery mechanism would be required, preferably one that utilized egg entry points ... but such a thing could be written as a bzr plugin in the classic style | 04:56 |
| rocky | so a plugin that allowed egg plugins | 04:56 |
| lifeless | kumi: revno: 3813 in trunk - Add contrib/bzr_ssh_path_limiter. (Andrew Bennetts) | 04:56 |
| lifeless | rocky: sure, just have a plugin which when loaded looks for eggs and loads them. | 04:56 |
| lifeless | rocky: note that all bzr plugins need to be loaded into the namespace cleanly - bzrlib.plugins.NAME | 04:57 |
| rocky | well, a plugin which looked for all eggs that provided a particular bzr entry point | 04:57 |
| rocky | lifeless: that's a silly requirement btw ;) | 04:57 |
| lifeless | rocky: rather than rehashing old ground, may I say that it works very well for us, allowing code reuse and simple configuration and deploymeny | 04:58 |
| rocky | sure and that's fine, i'm not saying discontinue the old way... just that cleanly working with eggs would help new python developers "get into" the plugin system easier | 04:59 |
| lifeless | we discover plugins using file system introspection and get the files to look for from python itself, so if eggs looked like packages and modules it would Just Work | 04:59 |
| rocky | does bzr understand the notion of a namespace package? | 04:59 |
| lifeless | bzrlib.plugins is one | 05:00 |
| rocky | good | 05:00 |
| lifeless | dunno if eggs will know it is, we write to python's core behaviour | 05:00 |
| rocky | so bzr just iterates over the list bzrlib.plugins.__path__ for all paths ? | 05:00 |
| lifeless | yes | 05:00 |
| lifeless | I recommend reading bzrlib.plugin | 05:00 |
| * rocky reads | 05:02 | |
| rocky | i think the main problem with an egg in this case is that it's packages won't get auto-imported which means they'll never get added to bzrlib.plugins.__path__ without some sort of kickstart | 05:03 |
| rocky | but i also see that bzrlib.plugin is actually setting (wholesale) bzrlib.plugins.__path__ which would worry me | 05:04 |
| rocky | and all of this would definately mean that zipped eggs wouldn't work | 05:05 |
| lifeless | so we set __path__ to pickup plugins from various places | 05:07 |
| lifeless | if there is a standard for getting a preset __path__ we can look at integrating that | 05:07 |
| lifeless | but what (I think) I said the other day basically applies: the bzr developers don't use eggs, someone interested in egg support needs to step up and collaborate | 05:08 |
| lifeless | we're not hostile to it | 05:08 |
| rocky | right -- a very sensible attitude | 05:10 |
| === jamesh_ is now known as jamesh | ||
| kumi | lifeless: thanks, that wrapper script isn't going to work for me though (it's for SSH) | 05:19 |
| kumi | wow, actually I just discovered /contrib/bzr_access | 05:22 |
| kumi | this looks exactly like what I'm looking for | 05:22 |
| kumi | It uses the command= directive in .ssh/authorized_key to restrict access only to bzr, and bzr_access.conf to control user/group-level access | 05:25 |
| lifeless | yes | 05:28 |
| lifeless | ssh auth is much more secure than anything we'd be likely to write | 05:29 |
| poolie | lifeless: so it looks like commit is actually failing in my current copy of your branch | 05:29 |
| lifeless | much better to reuse that than invent a new auth protocol | 05:29 |
| poolie | i'm hoping an update will fix it | 05:29 |
| kumi | That's perfect for me, the reason why I couldn't use bzr+ssh:// was because of the hassle involved in creating a chroot jail and all that | 05:29 |
| lifeless | kumi: oh no, you don't need a jail :) | 05:30 |
| kumi | :) | 05:30 |
| * kumi is happy | 05:30 | |
| lifeless | poolie: it's working for me | 05:30 |
| poolie | File "/home/mbp/bzr/repository-iter-changes/bzrlib/commit.py", line 701, in _report_and_accumulate_deletes | 05:30 |
| poolie | deleted_ids = set(self.basis_inv._byid.keys()) - \ | 05:30 |
| poolie | AttributeError: 'CHKInventory' object has no attribute '_byid' | 05:30 |
| poolie | it seems a bit odd it would be calling that | 05:30 |
| lifeless | poolie: are you using a MemoryTree? | 05:32 |
| poolie | yes, i'm using BranchBuilder | 05:33 |
| lifeless | poolie: basis_inv would have to be a CHKInventory for that to break; and AFAIK thats only the case with a MemoryTree | 05:33 |
| lifeless | righto, yes thats broken | 05:33 |
| lifeless | doing a full set difference is...bad anyhow | 05:33 |
| poolie | yes, it's a bit odd in commit | 05:33 |
| lifeless | its the fastest code we could do at the time; given its expecting a regular inventory | 05:34 |
| poolie | you're saying because if it was a dirstate tree it would use the basis tree from the dirstate? | 05:34 |
| lifeless | uhm spiv had a workaround I objected to; but perhaps a similar thing would get you past this | 05:34 |
| lifeless | yes, dirstate trees have the basis tree from the dirstate | 05:34 |
| poolie | i'm inclined to add an explicit method that returns all file ids | 05:35 |
| poolie | at the moment that's meant to be done by iter(inv) but that is a poor idea | 05:35 |
| lifeless | yah | 05:36 |
| lifeless | otoh | 05:36 |
| poolie | vila observes that we shouldn't add O(n) methods | 05:37 |
| poolie | so perhaps should fix commit now | 05:37 |
| lifeless | vila is right | 05:37 |
| poolie | otoh at the moment we do have a method, it's just poorly named as __iter__ | 05:37 |
| lifeless | otoh, commit is not broken for production use, for this project | 05:37 |
| lifeless | as this project is about historical trees | 05:37 |
| poolie | 'this project' = split inventories? | 05:38 |
| lifeless | yah | 05:38 |
| lifeless | I would be inclined to tweak commit to use __iter__ *for now* | 05:39 |
| lifeless | or even do an isinstance | 05:39 |
| poolie | vila says 'robert just added _report_and_accumulate_deletes'? | 05:39 |
| poolie | really? | 05:39 |
| poolie | it looks kind of old | 05:39 |
| lifeless | if instance(basis_inv, Inventory): byids else: set(iter(basis_inv)) | 05:39 |
| lifeless | set(by_id) is _really fast_ we don't want to lose that | 05:40 |
| poolie | lifeless (probably gone): so it looks like we need CHKInventory.apply_delta | 06:35 |
| thumper | poolie: hi, is spiv with you? | 06:42 |
| poolie | hi, yes he is | 06:43 |
| poolie | do you want him?+ | 06:49 |
| lifeless | poolie: why? | 06:55 |
| lifeless | poolie: (but sure, that should be easy enough, just hoist it up to the base class, test etc) | 06:56 |
| lifeless | or reimplement, making it into a dict delta | 06:56 |
| lifeless | which would be best | 06:56 |
| thumper | poolie: yeah, I'm talking with him about some weird hpss push problem with stacked branches | 07:03 |
| poolie | lifeless: regarding apply_delta, i think we want to change code so that it's not counting on mutating existing inventories | 07:11 |
| poolie | iow apply_delta should be deprecated in favour of create_by_apply_delta | 07:11 |
| lifeless | poolie: ack | 07:13 |
| lifeless | poolie: please, on the isinstance, trust me | 07:13 |
| poolie | if it's important i'd like to at least add a comment saying so | 07:14 |
| lifeless | poolie: set(dict.keys()) is slower than set(iter(dict)) | 07:14 |
| poolie | ok | 07:15 |
| lifeless | erm | 07:15 |
| lifeless | *faster* | 07:15 |
| poolie | hm | 07:16 |
| poolie | in that case i wonder if building two whole sets and subtracting them is actually faster | 07:16 |
| poolie | but the whole thing should be able to be removed | 07:16 |
| lifeless | I spent well over a month of my life profiling and tuning commit | 07:17 |
| lifeless | I assure you that the current code in that part of commit, with dirstate trees, is vulnerable to slowdowns by 'obvious' changes and minor perturbations | 07:18 |
| poolie | nice | 07:19 |
| lifeless | sorry, I'm not meaning to get snippy | 07:19 |
| poolie | np | 07:19 |
| poolie | i take your point and thanks for the warning | 07:20 |
| poolie | # the older Inventory classes provide a _byid dict, and building a | 07:21 |
| poolie | # set from this directly is substantially faster than even getting | 07:21 |
| poolie | # a set of ids from the inventory | 07:21 |
| lifeless | as a comment? sure | 07:21 |
| lifeless | I'd say | 07:22 |
| lifeless | "from the keys of this dict" | 07:22 |
| lifeless | because thats the critical thing - set(dict) ~= set(iter(dict)) < set(dict.keys()) | 07:22 |
| poolie | s/</>/? | 07:23 |
| poolie | yay perl :) | 07:23 |
| lifeless | set(dict) is roughly the same speed as set(iter(dict)) and both are significantly slower than set(dict.keys()) | 07:24 |
| poolie | oh, measuring goodness not time | 07:24 |
| poolie | iswym | 07:24 |
| lifeless | we don't want someone going 'the call to keys() is unneeded, I'll just clean it up here' | 07:25 |
| poolie | sure, that's why i want a comment | 07:25 |
| lifeless | right, I'm agreeing | 07:26 |
| poolie | no point discussing this and then doing it over and over | 07:26 |
| poolie | me too :) | 07:26 |
| lifeless | I'm saying your comment needs to say 'keys' in it :) | 07:26 |
| poolie | i see | 07:26 |
| poolie | that's kind of a bug in python if set(dict) is evaluated as set(iter(dict)) when the other would be faster | 07:27 |
| poolie | well, 'bug' might be too strong | 07:27 |
| lifeless | feature clearly | 07:27 |
| lifeless | but this is what I mean by obvious cleanups | 07:27 |
| lifeless | semantically set(dict) == set(dict.keys()), but performance wise they are rather different | 07:27 |
| poolie | i'm going to do the isinstance on both of them | 07:28 |
| lifeless | what will the fallback be then? | 07:28 |
| poolie | do you want me to send a new patch just for this, or just keep it in my branch? | 07:28 |
| poolie | http://pastebin.ubuntu.com/69911/ | 07:29 |
| lifeless | new patch would be good; we can review it and send it to trunk | 07:29 |
| lifeless | yah, looks good to me, bb:approve | 07:29 |
| poolie | oh i guess this can actually go in to trunk now | 07:30 |
| poolie | ok | 07:30 |
| lifeless | wait a sec | 07:31 |
| lifeless | damn python, things keep changing ... | 07:31 |
| lifeless | robertc@lifeless-64:~$ python -m timeit -s "f = dict((str(num), str(num + 1)) for num in xrange(50000))" "set(f)" | 07:31 |
| lifeless | 100 loops, best of 3: 15.9 msec per loop | 07:31 |
| lifeless | robertc@lifeless-64:~$ python -m timeit -s "f = dict((str(num), str(num + 1)) for num in xrange(50000))" "set(f.keys())" | 07:31 |
| lifeless | 10 loops, best of 3: 23.3 msec per loop | 07:31 |
| lifeless | robertc@lifeless-64:~$ python -m timeit -s "f = dict((str(num), str(num + 1)) for num in xrange(50000))" "set(iter(f))" | 07:31 |
| lifeless | 100 loops, best of 3: 17.2 msec per loop | 07:31 |
| lifeless | so set(f) is appearing to be the fastest thing now | 07:31 |
| lifeless | sometimes I hate python | 07:33 |
| lifeless | looks like any change here will need solid reprofiling | 07:33 |
| lifeless | <garh> | 07:33 |
| AfC | Robert: "sometimes I hate python". I'm going to write that down, I think | 07:33 |
| poolie | i'm pretty sure the whole thing can be removed since we _should_ have this data from iter_changes | 07:33 |
| lifeless | my advice would be the isinstance, with the comment tweaked to advise that we were cautious in the lack of time to profile | 07:33 |
| lifeless | poolie: but we aren't using iter_changes yet | 07:34 |
| lifeless | poolie: I mean, I agree in principle; but today it isn't the case that we can use iter_changes trivially | 07:35 |
| poolie | sorry, i meant from _populate_from_inventory | 07:35 |
| lifeless | igc did a patch which came close | 07:35 |
| poolie | which seems to know about deletions too | 07:35 |
| poolie | but i don't want to look closely into it now | 07:35 |
| poolie | i might ask ian about that this week | 07:35 |
| poolie | afc, familiarity breeds contempt (amongst other things) :) | 07:36 |
| lifeless | we didn't have an answer for iter_changes during commit of a merge | 07:36 |
| lifeless | and | 07:36 |
| lifeless | having two code paths was very concerning to me at least, for this particular bit of code, commit is kinda critical | 07:36 |
| lifeless | now, I think I have an answer for iter_changes and merges, but its very different to what igc had been putting together | 07:37 |
| lifeless | I'll drop a mail to the list | 07:37 |
| poolie | if you like, it's not immediately in our queue | 07:40 |
| poolie | for now, vincent and i are going to make inventory stuff more CoW, maybe deprecating methods that aren't | 07:40 |
| poolie | btw "i hate python" reminds me of http://lambda-the-ultimate.org/node/510 | 07:41 |
| poolie | actually not precisely that but i can't find the precise link | 07:41 |
| poolie | >> I suspect that the best thing a GC can provide is a predictable performance model that programmers can understand and use. | 07:41 |
| lifeless | poolie: where is apply_delta being used btw | 07:42 |
| * poolie pops stacks | 07:53 | |
| poolie | in commit i think | 07:53 |
| poolie | calling update_basis_by_delta; the default implementation of that calls it | 07:53 |
| poolie | the non-dirstate case again | 07:53 |
| lifeless | hmm | 07:55 |
| lifeless | the basis can't be updated in a memorytree anyhow | 07:56 |
| lifeless | poolie: I'd be inclined to override update_basis_by_delta on MemoryTree | 07:57 |
| lifeless | poolie: avoids the issue entirely, and faster too | 07:57 |
| === jszakmeister|awa is now known as jszakmeister | ||
| thumper | yay for `bzr info -v` not taking ages and counting disk size | 08:10 |
| kumi | bzr_access works, yay | 08:22 |
| poolie | yay | 08:24 |
| kumi | If I branch from serverA to serverB, both branches can either pull or push to each other, correct? | 08:25 |
| poolie | correct | 08:26 |
| kumi | awesome | 08:26 |
| kumi | I just upgrade from 0.92 to 1.9-rich-root. This is blazing fast | 08:29 |
| poolie | that's great! | 08:30 |
| poolie | what are you storing? | 08:30 |
| kumi | A small website | 08:31 |
| kumi | I'm not sure if rich-root was the right choice, I didn't find any info about it | 08:31 |
| kumi | just that it's advised for bzr-svn | 08:32 |
| === eMBee_ is now known as eMBee | ||
| thumper | kumi: rich root will become the defacto standard sometime in the (hopefully) near future | 08:56 |
| hno | thumper: What is rich-root about? | 09:06 |
| thumper | hno: rich-root formats store extra information about the root directory, sorry I don't know much more than that | 09:07 |
| thumper | bzr-svn needs to know more about the root | 09:07 |
| thumper | it is also required for nested-tree support (I believe) | 09:07 |
| thumper | I don't know what in particular it needs either | 09:07 |
| hno | doesn't say much.. | 09:07 |
| thumper | no | 09:08 |
| kumi | anything that gets us closer to nested trees is A-OK | 09:18 |
| kumi | in my book | 09:18 |
| hno | Found this in the bzr-1.0 news: New rich-root and rich-root-pack formats, recording the same data about tree roots that's recorded for all other directories. (Aaron Bentley, #164639) | 09:21 |
| jszakmeister | jelmer: you around? | 09:48 |
| === jszakmeister is now known as jszakmeister|awa | ||
| _tsatbic_ | I've got a question about the selftest. I installed bzr-1.9 from source. I installed on "CentOS release 5 on x86_64" and on "Debian release 4.0". | 13:31 |
| _tsatbic_ | I run selftest on both systems and do not know how to interpret the results. | 13:32 |
| _tsatbic_ | I've got 873 tests skipped, 2 and 4 failures, 1 error and 12 and 15 known_failure_count | 13:33 |
| _tsatbic_ | the word FAILED is written in capital letters | 13:34 |
| gnomefreak | how would i remove a pending merge? | 15:17 |
| beuno | gnomefreak, bzr revert --forget-merges | 15:18 |
| gnomefreak | thanks | 15:18 |
| === kiko is now known as kiko-fud | ||
| rocky | jelmer: new bzr-svn issue for you... or perhaps you can show me what i'm doing wrong -- http://cluebin.appspot.com/pasted/2603 | 16:44 |
| jelmer | rocky, that's bug 293440 | 16:46 |
| ubottu | Launchpad bug 293440 in bzr "Cannot commit to bound svn branch: "invalid property value 'branch-nick' for None"" [High,Fix released] https://launchpad.net/bugs/293440 | 16:47 |
| rocky | oh good, it's no just me | 16:47 |
| * rocky looks for a work around | 16:47 | |
| rocky | jelmer: so essentially this is a bzr 1.9 bug ? (do you know if it's been applied to the bzr 1.9 branch?) | 16:48 |
| rocky | err... if the fix has | 16:48 |
| jelmer | there's a proposed patch attached | 16:48 |
| jelmer | no, it hasn't made it in yet | 16:48 |
| * rocky unbinds and pushes | 16:53 | |
| jelmer | a workaround is to set a nickname locally I think | 16:59 |
| rocky | oh i've never set a branch nick name before, didn't know there was such a thing | 17:10 |
| rocky | jelmer: what i've been working on is http://pypi.python.org/pypi/ClueBzrServer | 17:10 |
| jelmer | rocky, ah, nice | 17:12 |
| jelmer | rocky, any plans to integrate loggerhead? | 17:12 |
| rocky | jelmer: not currently, but honestly i had no plans to do anything so who knows ;) | 17:15 |
| rocky | if loggerhead is just another wsgi app it should be pretty straight forward | 17:15 |
| jelmer | it is, afaik | 17:15 |
| rocky | course the real reason i'm working on this is to hook it up to the full ClueMapper suite which is basically a way of managing multiple trac instances with multiple (currentlly svn only) repos | 17:16 |
| rocky | but i figured it's useful outside the ClueMapper suite | 17:16 |
| rocky | kumi: is http://pypi.python.org/pypi/ClueBzrServer something like what you were looking for last night? | 17:27 |
| jelmer | rocky, can you perhaps announce cluebzrserver on the bazaar list? | 17:30 |
| jelmer | rocky, I suspect there are more people interested in this sort of thing | 17:32 |
| kumi | rocky: yeah, the convenience factor with your tool seems high | 17:32 |
| kumi | although I went with contrib/bzr_access | 17:32 |
| === kiko-fud is now known as kiko | ||
| rocky | kumi: my tool supports ldap auth :) | 17:39 |
| rocky | jelmer: yeah i should subscribe to bazaar list | 17:40 |
| rocky | jelmer: which list? | 17:42 |
| rocky | users/developers i guess | 17:42 |
| jelmer | bazaar-list@lists.canonical.com | 17:42 |
| jelmer | there's just one list, nothing specific for developers or users | 17:43 |
| rocky | jelmer: you put a bad link in http://bazaar-vcs.org/BzrForeignBranches/Subversion for 0.4.15 | 17:45 |
| jelmer | rocky, thanks, fixed | 17:45 |
| rocky | jelmer: do you know if loggerhead 1.6 works with bzr 1.9 ? | 18:14 |
| jelmer | rocky, don't know | 18:15 |
| jelmer | rocky, I think so | 18:15 |
| rocky | it's a pretty straightforward app, wsgi and the like | 18:15 |
| rocky | jelmer: btw, it's almost certainly not possible to have bzr-svn setup properly as an egg because the "location" of the plugin is very important for bzr and that can't be controlled via egg | 18:15 |
| jelmer | rocky, ah, ok | 18:16 |
| jelmer | rocky, in that case, it won't work for any of the bzr plugins | 18:16 |
| rocky | jelmer: exactly | 18:16 |
| rocky | i discussed that with lifeless a bit last night, basically the conclusion is that nobody that's really interested in eggs is working with bzr code | 18:17 |
| rocky | but they would probably welcome a patch | 18:17 |
| rocky | i might have a swing at it one of these days... set it up so plugins can be defined via egg entry points (that also means an egg can contain more than one bzr plugin) | 18:17 |
| jelmer | yeah, I agree it would be good to have support for eggs | 18:26 |
| jelmer | even though I use them myself | 18:26 |
| jelmer | even though I *don't* use them myself | 18:28 |
| rocky | jelmer: if i'm going to start pplaying with trac 0.11 and bzr 1.9 ... which trac-bzr branch should i look at? | 18:39 |
| * rocky thinks experimental might be his best bet | 18:39 | |
| === mxpxpod is now known as mx|lunch | ||
| jfroy|work | yeah, I've had issues in the past where plugins would be installed as eggs and essentially not be loaded | 18:47 |
| jfroy|work | Ideally Bazaar should publish some guidelines or boilerplate distutils code to help plugins authors distribute their plugins in a manner compatible with easy_install, such that users could install plugins through their OS's package manager, through running setup.py (from a source distribution or a bazaar branch or checkout) and through easy_install. | 18:49 |
| * jfroy|work is reminded of the sad, sad state of Python package installation | 18:49 | |
| rocky | jfroy|work: atm it's simply not possible to do what you suggest with eggs/plugins without modifying bzr somehow to look up egg entry points | 18:51 |
| rocky | basically the way bzr plugins works now works *against* how eggs work | 18:51 |
| jfroy|work | Yeah, I know. | 18:52 |
| rocky | in fact, anything that relies on __path__ works *against* eggs | 18:52 |
| jfroy|work | I don't think we should support eggs necessarily | 18:52 |
| jfroy|work | Just make sure easy_install / setuptools never install Bazaar plugins as eggs | 18:52 |
| rocky | i don't think that's possible either ;) | 18:52 |
| rocky | easy_install will try to install any distutils-activated tarball/directory | 18:52 |
| rocky | it should be pretty straightforward to write a standard bzr plugin that enables plugins via eggs | 18:53 |
| jfroy|work | lol | 18:53 |
| rocky | so a meta plugin of sorts | 18:53 |
| jfroy|work | that's so ... meta, yeah | 18:53 |
| jfroy|work | :) | 18:53 |
| rocky | but either which way, i can understand if nobody is interested enough in eggs to implement any of this, but nobody should be opposed to it either ;) | 18:54 |
| jelmer | rocky, the trunk | 18:56 |
| * rocky switches to trunk | 18:56 | |
| jelmer | rocky, experimental is the branch used for Debian experimental | 18:57 |
| jelmer | it's basically trunk with a debian/ directory | 18:57 |
| rocky | jelmer: so lp:trac-bzr then? | 18:57 |
| jelmer | rocky, yep | 18:57 |
| rocky | jelmer: where does bzr+debug logging typically go? i don't *think* i'm seeing it in console when i turn on trac debugging | 18:59 |
| jelmer | ~/.bzr.log | 19:00 |
| rocky | really? i'm not seeing *anything* there | 19:02 |
| LarstiQ | right user? | 19:02 |
| rocky | yeah, this is a test environment i'm running right now all running under my personal user account | 19:02 |
| rocky | ah i kind of see what's going on here ... if i try browsing to a branch that is empty, i get an error ... (<p class="message">No node MyProject/trunk at revision current:</p><p>You can <a href="/pm/p/testbzr/log/MyProject/trunk?rev=current%3A&mode=path_history">search</a> in the repository history to see if that path existed but was later removed</p>) | 19:04 |
| rocky | whoops, didn't realize that was going to be so much | 19:04 |
| rocky | but if i add a file to that branch, it views fine | 19:05 |
| LarstiQ | does it need to have files, or revisions? Ie, ci --unchanged on an empty branch. | 19:06 |
| rocky | it shouldn't have to, but i mean trac shouldn't be reporting an error when it doesn't | 19:07 |
| rocky | jelmer: i'm still running into bizarre commit issues .... i just did the following: | 19:22 |
| rocky | 1) bzr co https://somesvnproject/trunk svnproject-trunk | 19:22 |
| rocky | 2) bzr branch svnproject-trunk svnproject-mybranch | 19:22 |
| rocky | 3) changed some files in mybranch | 19:22 |
| rocky | 4) committed files in my branch | 19:22 |
| rocky | 5) bzr push https://somesvnproject/branches/mybranch | 19:22 |
| rocky | and after doing all this, the changes i made actually get committed back to trunk and my remote branch dir is empty | 19:22 |
| rocky | am i doing something stupid again? | 19:22 |
| jelmer | rocky: can you show me the svn log output from that particular revision? | 19:23 |
| rocky | well, doing a push did two svn commits | 19:24 |
| rocky | one commit created the empty branch folder, the second commit updated the files in (incorrectly) trunk | 19:24 |
| rocky | lemme dig up the revs | 19:24 |
| rocky | jelmer: what "svn log" output are you looking for? | 19:24 |
| LarstiQ | that sounds familiar | 19:24 |
| jelmer | rocky: so mybranch didn't exist before? | 19:24 |
| rocky | jelmer: no it did not | 19:24 |
| jelmer | rocky, the last few revisions | 19:25 |
| jelmer | rocky, use "bzr svn-push" for new branches - bug 127945 | 19:25 |
| ubottu | Launchpad bug 127945 in bzr "Integrate creating new branch functionality into standard push/branch" [High,In progress] https://launchpad.net/bugs/127945 | 19:25 |
| LarstiQ | jelmer: if it helps, I had svn mkdired a branch dir, bzr pushed to it, and got what was in trunk (instead of my diverged branch) in there | 19:25 |
| rocky | jelmer: you can see what i did with http://projects.serverzen.com/pm/p/cluemapper/timeline where the last two revs is where i backed things out | 19:25 |
| jelmer | rocky, LarstiQ: please file a bug | 19:26 |
| rocky | jelmer: looks like using svn-push did the right thing ... so i guess it was just that i wasn't using the push properly | 19:27 |
| rocky | due to that bug you mentioned | 19:27 |
| LarstiQ | jelmer: noting it down to do first thing tomorrow when I'm back at that repository | 19:28 |
| rocky | jelmer: the bzr ancestry property here http://projects.serverzen.com/pm/p/cluemapper/browser/ClueMapper/branches/rocky-bzr is crazy ;) | 19:29 |
| jelmer | wow, yeah :-) | 19:29 |
| jelmer | LarstiQ, thx :-) | 19:29 |
| jfroy|work | OK, time to try bzr-svn again | 19:34 |
| jfroy|work | With the awesomely tortured svn repository | 19:34 |
| jfroy|work | jelmer: http://pastie.org/311636 | 19:47 |
| jelmer | jfroy|work, please use 0.4, not trunk | 19:48 |
| jfroy|work | I'm pretty sure I need 0.5's more flexible repository layout support | 19:49 |
| jfroy|work | Is 0.4 TOT viable? | 19:49 |
| jelmer | jfroy|work, TOT? | 19:50 |
| jfroy|work | top of tree | 19:50 |
| jfroy|work | sorry :/ | 19:50 |
| jelmer | yeah, 0.4 should work fine | 19:50 |
| jelmer | I've pushed a fix for trunk as well for the issue you mentioned | 19:51 |
| jelmer | but running trunk on production stuff is asking for trouble.. | 19:51 |
| jfroy|work | before I kick off the next command, what debug flags would be useful to you? | 19:55 |
| jelmer | it depends on the error | 19:56 |
| jfroy|work | Alright, here goes | 19:56 |
| jfroy|work | Running on revision 1755 | 19:56 |
| jfroy|work | blank config (no subversion.conf, no cache) | 19:56 |
| jfroy|work | whoa | 20:00 |
| jfroy|work | it worked | 20:00 |
| * jfroy|work is very impressed. | 20:00 | |
| jelmer | cool :-) | 20:02 |
| jfroy|work | tip of the hat | 20:04 |
| jfroy|work | I tried two different branches in that common repository of hell, both checked out fine | 20:04 |
| jfroy|work | (two different projects) | 20:04 |
| jfroy|work | w/o to commits and merging, what is the proper sequence of way such that each commit made in bazaar will be a separate commit in Subversion? | 20:05 |
| jfroy|work | IIRC given trunk, a checkout of a svn branch, and trunk-dev, a Bazaar branch of trunk, you should not from trunk merge trunk-dev, as that will yield one svn commit for the merge (with all the changes merged from the branch). | 20:07 |
| jfroy|work | I think pushing from trunk-dev into trunk does the trick, merging trunk into trunk-dev before pushing. | 20:07 |
| jfroy|work | Or is that bad? | 20:07 |
| jelmer | jfroy|work, yeah, basically - only things that are in the mainline of hte bzr branch end up in svn | 20:10 |
| jelmer | jfroy|work, merging trunk into trunk-dev won't work, since that changes the mainline in svn | 20:11 |
| jfroy|work | Right, and a merge is a single item with a hierarchy of changesets below it coming from the other branch | 20:11 |
| jelmer | jfroy|work, you may want to look at the bzr-svn FAQ | 20:11 |
| jelmer | 'morning thumper | 20:11 |
| jfroy|work | jelmer: not sure I understand that FAQ item :p I'm not well versed enough in DCVS theory to really understand what it is saying | 20:13 |
| jfroy|work | My short question is: what's the best practice to stay out of trouble, in general | 20:13 |
| jelmer | use bzr rebase | 20:14 |
| jelmer | is the simplest answer there | 20:15 |
| jfroy|work | I've never used that :p | 20:16 |
| jelmer | it replays the revisions unique to trunk-dev on top of trunk, basically | 20:16 |
| jelmer | so you keep a linear history (no right hand side stuff) | 20:16 |
| jfroy|work | So I see | 20:18 |
| jfroy|work | So would, inside trunk, rebase ../trunk-dev amount to pushing from trunk-dev to trunk, provided they have no diverged? | 20:19 |
| jfroy|work | *not | 20:19 |
| jfroy|work | **not diverged | 20:19 |
| jelmer | yes, with newer versions of bzr-rebase | 20:20 |
| jelmer | older versions will just yell at you and tell you to use "bzr pull" instead :-) | 20:20 |
| jfroy|work | lol | 20:20 |
| jfroy|work | I see | 20:20 |
| jfroy|work | right, a pull would do that | 20:20 |
| jfroy|work | The issue is when the branches have diverged, I suppose. | 20:20 |
| jfroy|work | Ideally, I want a workflow where I have a checkout of trunk from subversion, with a set of work branches. | 20:21 |
| LarstiQ | isn't renase ../trunk-dev the wrong way around? | 20:21 |
| jfroy|work | I want to be able to pull changes from trunk into those work branches periodically to keep up with trunk, and push changes from those work branches into the svn trunk branch when appropriate. | 20:21 |
| jelmer | LarstiQ, yes, you usually spell it with a "b" :-P | 20:21 |
| jfroy|work | LarstiQ: yes I just noticed that | 20:22 |
| thumper | hi jelmer | 20:22 |
| jfroy|work | you rebase inside trunk-dev, onto trunk (or by default the parent branch) | 20:22 |
| jelmer | jfroy|work, rebase will allow you to do that | 20:22 |
| LarstiQ | jelmer: :P | 20:22 |
| jfroy|work | So the workflow is basically, from the work branches, bzr merge ../trunk | 20:22 |
| LarstiQ | jelmer: I meant rebasing svn trunk on top of bzr diverged seems off.. | 20:23 |
| jfroy|work | To pull changes that have been committed to Subversion's trunk | 20:23 |
| jfroy|work | And bzr rebase from those work branches to send those changes to trunk | 20:23 |
| jelmer | jfroy|work, no, the other way around | 20:23 |
| jelmer | jfroy|work, bzr rebase to pull in changes from svn trunk and bzr push to make changes go into svn trunk | 20:24 |
| * jfroy|work is hopelessly confused now. | 20:24 | |
| jfroy|work | Ahh, gotcha. | 20:24 |
| jelmer | sorry | 20:24 |
| LarstiQ | now I am confused. | 20:24 |
| jfroy|work | No it's entirely my fault :p | 20:24 |
| * jfroy|work casts confuse on #bzr | 20:24 | |
| LarstiQ | jfroy|work: well, jelmer's explanation confuses me. | 20:24 |
| jelmer | LarstiQ, which bit, specifically? | 20:24 |
| LarstiQ | jelmer: bzr rebase pulling in changes from svn | 20:25 |
| jelmer | LarstiQ, if you have a feature branch, you can "bzr rebase" on top of the svn trunk | 20:26 |
| jfroy|work | right, it basically will find the changesets in the current branch that are not in svn trunk | 20:27 |
| LarstiQ | jelmer: right, but I understand that as running from the feature branch with trunk as argument. | 20:27 |
| jfroy|work | Then alter the history of the current branch to the top of svn trunk, and replay the identified changesets. | 20:27 |
| jelmer | LarstiQ, yes, that's correct | 20:27 |
| jfroy|work | yup | 20:27 |
| LarstiQ | jelmer: ok, unconfused then. | 20:27 |
| jelmer | jfroy|work, correct | 20:28 |
| jfroy|work | Which means that after that, the branches will not have diverged. | 20:28 |
| jelmer | jfroy|work, correct | 20:28 |
| jfroy|work | And you can either either push to svn trunk or pull from svn trunk | 20:28 |
| jfroy|work | *And you can then either | 20:28 |
| jfroy|work | Which will happily send changes to subversion | 20:28 |
| LarstiQ | it will mean anything depending on your old revisions will miss them | 20:29 |
| jfroy|work | *send the changes | 20:29 |
| jfroy|work | LarstiQ: hum? | 20:29 |
| LarstiQ | jfroy|work: if you branch the feature-branch to 'dependant', rebase the feature-branch on top of trunk, doing a pull in 'dependant' will mention divergence | 20:30 |
| jfroy|work | right | 20:31 |
| jfroy|work | you'll have to chain rebase down the branch children | 20:31 |
| jfroy|work | rebase feature on trunk, rebase dependent on feature, etc | 20:31 |
| LarstiQ | yeah, or pull --overwrite | 20:31 |
| * LarstiQ nods | 20:31 | |
| LarstiQ | if you actually have changes | 20:31 |
| jfroy|work | Isn't --overwrite evil? | 20:32 |
| jfroy|work | :p | 20:32 |
| LarstiQ | jfroy|work: I consider it less evil than rebase :) | 20:32 |
| jfroy|work | jelmer: but your advise is that rebase is the best way to go, with respect to bzr-svn, correct? | 20:32 |
| jelmer | IFF you need to keep the mainline history intact, yes | 20:33 |
| jfroy|work | *advice | 20:33 |
| jfroy|work | Merging feature into trunk will work as well, correct? | 20:34 |
| jfroy|work | Or will there be issues with that, beyond the single commit to Subversion for the entire set of changes merged in. | 20:35 |
| jelmer | no, that should work ok | 20:36 |
| jfroy|work | Your FAQ mentions you can merge into a checkout of trunk, or rebase on trunk | 20:36 |
| jfroy|work | OK | 20:36 |
| jelmer | be sure to use bzr-svn 0.4.15, btw | 20:36 |
| jelmer | (or the 0.4 branch) | 20:36 |
| jfroy|work | I am using 0.4.16dev0 | 20:37 |
| jfroy|work | Oh, BTW | 20:37 |
| jelmer | that's recent enough :-) | 20:37 |
| jfroy|work | I noticed that 0.4.15 reports as 0.4.15dev0 | 20:37 |
| jfroy|work | When I installed the bzr 1.9 Mac OS X 10.5 package this morning | 20:37 |
| jelmer | yeah, I forgot to set "final" | 20:37 |
| jfroy|work | I built the bzr-svn package for that | 20:37 |
| jfroy|work | OK | 20:37 |
| jfroy|work | Wasnm | 20:37 |
| jelmer | but it didn't seem worth it to release a 0.4.15a or 0.4.16 just for that | 20:38 |
| jfroy|work | For a moment I was worried I somehow built from an outdated source distribution... | 20:38 |
| jfroy|work | Anything important in 0.4.16 over .15? | 20:42 |
| jfroy|work | In other words, should I tell people to install 0.4.16 on top of .15 right now? | 20:42 |
| LarstiQ | it seems to me .16 is not released yet? | 20:45 |
| jelmer | yeah, 0.4.16 isn't out yet :-) | 20:47 |
| jfroy|work | jelmer: http://pastie.org/311689 :| | 20:47 |
| jelmer | jfroy|work, that's a known bzr bug - bug 293440 | 20:48 |
| ubottu | Launchpad bug 293440 in bzr "Cannot commit to bound svn branch: "invalid property value 'branch-nick' for None"" [High,Fix committed] https://launchpad.net/bugs/293440 | 20:48 |
| jfroy|work | I see | 20:48 |
| jfroy|work | So basically, no bound branches for now | 20:55 |
| jfroy|work | jelmer: everything seems to be working fine | 21:13 |
| jelmer | cool | 21:14 |
| dwt | Hey guys, I'm getting a ERROR: bzrlib.errors.KnitCorrupt when updating from a svn host | 21:20 |
| dwt | all the while bzr check is sure that nothing is wrong with the repository | 21:20 |
| dwt | could someone advise on how to track this down further? | 21:20 |
| jelmer | dwt: Hi | 21:24 |
| jelmer | dwt, what version of bzr-svn ? | 21:25 |
| dwt | jelmer: Evening! | 21:25 |
| dwt | 1.9 I installed | 21:25 |
| jelmer | but what version of bzr-svn? | 21:25 |
| dwt | just a second | 21:26 |
| jelmer | 0.4.15 contains a fix for this | 21:27 |
| dwt | bzr-svn 0.4.15 | 21:27 |
| dwt | thats what my NEWS file says at least | 21:27 |
| dwt | is there a better way to get the version of bzr-svn? | 21:27 |
| jelmer | dwt, please try removing ~/.bazaar/svn-cache and doing a clean checkout | 21:27 |
| dwt | :-/ | 21:27 |
| dwt | Thats going to take about 6 hours | 21:28 |
| LarstiQ | ouch | 21:28 |
| dwt | Is there a shortcut? | 21:28 |
| james_w | abentley: hi, would you have a few minutes to help debug this issue with autopacking stacked branches? | 21:28 |
| abentley | james_w: No, because I'm debugging an issue with autopacking stacked branches. | 21:29 |
| dwt | I mean, I don't really need the history | 21:29 |
| dwt | I'd love to just get the last 100 revisions or something like that | 21:29 |
| james_w | abentley: heh, fair enough :-) | 21:29 |
| dwt | if possible | 21:29 |
| jelmer | bzr-svn 0.4 has some experimental support for stacked branches, but will still have to figure out the file ids and thus analyse all revisions | 21:30 |
| dwt | by the way: whats the easiest way to find out at what revision my checkout exactly is? | 21:30 |
| jelmer | dwt, bzr revno or "bzr version-info" | 21:31 |
| dwt | jelmer: thanks! | 21:31 |
| jelmer | dwt, is this a public repository? | 21:32 |
| dwt | yes | 21:32 |
| dwt | svn://svn.adiumx.com/adium/trunk | 21:32 |
| dwt | jelmer: I just updated to the latest version of the stable-branch and am trying it again from there (from the news file this seems to be "bzr-svn 0.4.16 UNRELEASED" | 21:34 |
| dwt | ) | 21:34 |
| * LarstiQ nods | 21:34 | |
| * dwt :) | 21:35 | |
| dwt | Uh wow! | 21:36 |
| dwt | it got throuth it! | 21:37 |
| dwt | YES! | 21:37 |
| dwt | :) | 21:37 |
| dwt | (Sorry for the cry of joy. :) | 21:37 |
| jelmer | dwt, :-) | 21:38 |
| dwt | (Just for the record: my git-svn import of that same repository still dies on a bug in the git 1.6.0.2 that ought to be fixed only in 1.6.0.3 ;) | 21:38 |
| dwt | but which I still can't verify | 21:38 |
| dwt | Ah well. Have a nice day! (On with my work on adium) | 21:40 |
| jelmer | There's no open bugs wrt importing svn repositories in bzr-svn atm | 21:40 |
| jelmer | Not sure whether that's just because there are none or because people don't report them.. | 21:40 |
| jelmer | dwt: :-) | 21:41 |
| fullermd | As long as nobody reports bugs, there aren't any. | 21:41 |
| dwt | :) | 21:41 |
| fullermd | Ergo, all bugs are user-inflicted. | 21:41 |
| dwt | Well, it works for me now - though I'm using the unreleased version | 21:41 |
| jelmer | 0.4.16 doesn't contain any changes that could influence this that aren't in 0.4.15 | 21:42 |
| dwt | great | 21:42 |
| dwt | so it seems I've not been on the correct checkout of 4.15 - | 21:43 |
| dwt | Must be that I've updated too early from the stable repo | 21:43 |
| dwt | (about satturday) | 21:43 |
| jelmer | ah, yeah, it was fixed later than that I think | 21:44 |
| dwt | damn. :) | 21:46 |
| === bac is now known as bac_afk | ||
| lifeless | moin | 21:58 |
| lifeless | james_w: perhaps I can help, once I have caffeinated | 21:59 |
| james_w | lifeless: I'm sure you could | 21:59 |
| lifeless | james_w: so, while I hunt down caffeine, can you describe whats up | 22:01 |
| james_w | just pulling up the bug number | 22:01 |
| james_w | bug 288751 | 22:01 |
| ubottu | Launchpad bug 288751 in bzr "bzr push returns error Revision <x> not in <y>" [Critical,Triaged] https://launchpad.net/bugs/288751 | 22:01 |
| lifeless | ok, so thats autopackin related? cool - I know abentley is fixing that; I thought you might have another case | 22:02 |
| james_w | I'm with gmb and he just hit it, so I wanted to grab some information while there were live branches | 22:02 |
| james_w | yeah, it sounds like Aaron is on it | 22:02 |
| lifeless | try bzr pack <target branch> | 22:02 |
| abentley | lifeless: It depends which autopacking bug you mean. | 22:03 |
| abentley | lifeless: We've got plenty of them. | 22:03 |
| lifeless | oh :( | 22:03 |
| lifeless | I thought there was just one left | 22:03 |
| abentley | lifeless: No, there are at least three. | 22:03 |
| lifeless | grah | 22:04 |
| lifeless | so, stab in the dark, ifyou disable spiv's smart verb, do they go away? | 22:04 |
| abentley | lifeless: No. Codehosting is on 1.7, so it doesn't support the smart verb. | 22:04 |
| lifeless | ah, true enough | 22:05 |
| lifeless | must caffeinate, brb | 22:05 |
| james_w | ta-da! | 22:06 |
| gmb | lifeless: Morning. I has pastebins for you | 22:07 |
| gmb | lifeless: https://pastebin.canonical.com/11006/ (Traceback) | 22:07 |
| gmb | lifeless: https://pastebin.canonical.com/11007/ (bzr.log) | 22:07 |
| james_w | from what I have been able to discern, when it does the autopack it can no longer find some text compression parents in the combined indices. | 22:11 |
| james_w | in this case there were two missing parents, from two different file ids | 22:12 |
| james_w | both file ids were modified in the revisions being pushed | 22:12 |
| james_w | the missing parents were from a while ago, September and June. | 22:13 |
| james_w | the missing parents were the last revisions to modify the files in question though | 22:15 |
| james_w | though both were revisions merged by PQM | 22:15 |
| lifeless | abentley: is the one james_w is talking about the one you are investigating ? | 22:16 |
| lifeless | james_w: so the question is 'why' - we're not meant to ever delta compress across repository boundaries; its not safe. | 22:17 |
| lifeless | so either there is another bug elsewhere allowing that to happen (plausible), or we are dropping some index that matters at autopack (less plausible) | 22:19 |
| abentley | lifeless: it sounds like #288751, which I will do, but not what I'm working on. | 22:20 |
| lifeless | james_w: if you're interested in helping, writing a little script to open a repo, and scan all its indices for missing compression parents would be good | 22:20 |
| lifeless | abentley: ok, I'll chase it a little to clarify it, but will get back to the inventory stuff once its clear | 22:21 |
| abentley | lifeless: I don't recall any requirement that delta compression avoid revision boundaries. | 22:21 |
| abentley | s/revision/repository | 22:21 |
| james_w | lifeless: but would that help? It seems like it is at the autopack stage, so analysing the repository before may not tell us anything. | 22:21 |
| lifeless | the discussion may have happened on irc | 22:21 |
| lifeless | james_w: it will tell us if that theory is false | 22:21 |
| james_w | lifeless: true | 22:22 |
| lifeless | and if it fails to disprove the theory, we can continue looking for falsification - or even confirmation :> | 22:22 |
| lifeless | abentley: the discussion may have happened on IRC. I'll look for a list message; I'm fairly sure there are docstrings mentioning it. | 22:22 |
| lifeless | abentley: the reasoning I recall was : to allow smart servers to always be able to operate on their repository contents, without requiring third-party connections (like e.g. site-to-site ftp) | 22:23 |
| abentley | lifeless: Well, it wouldn't surprise me at all if your first commit to a stacked branch was all deltas. | 22:23 |
| thumper | spiv: ping | 22:24 |
| lifeless | abentley: bzr should not delta (unless the basis revision was pulled across) | 22:24 |
| abentley | lifeless: I am certain that the smart server attempts to access remote repositories, because it gets a publickey error | 22:26 |
| lifeless | abentley: ugh; thats definitely not what was intended | 22:26 |
| lifeless | abentley: 'doc/developers/overview.txt' has prose about this | 22:27 |
| lifeless | under the 'Stacked Repositories' section | 22:28 |
| lifeless | and, <3 bzr-search | 22:28 |
| lifeless | which found this immediately after I failed with google :) | 22:28 |
| abentley | So, perhaps commit honours this contract and push doesn't. But something is rotten. | 22:30 |
| poolie | hello lifeless, abentley, james_w | 22:33 |
| abentley | poolie: hi | 22:33 |
| james_w | hi poolie | 22:34 |
| thumper | hi poolie | 22:36 |
| thumper | poolie: abentley and I are trying to track down the source of the hpss push problem we are seeing | 22:36 |
| abentley | thumper: I seem to be reproducing it at last. | 22:36 |
| thumper | abentley: \o/ | 22:37 |
| abentley | thumper: What was the bug number again? | 22:37 |
| lifeless | abentley: ack | 22:37 |
| lifeless | abentley: do you have a stack trace of the server side op that is trying to make a connection? (I'm curious about why anything would be trying that) | 22:39 |
| abentley | lifeless: Not at present, but it's not hard. Just mirror a stacked branch off launchpad, change its stacked_on URL to a remote one, and push into it. | 22:40 |
| lifeless | abentley: ah, so you're using your local bzr version at that point - I bet that that is the autopack kicking in | 22:41 |
| lifeless | spiv should be around in about 20 minutes | 22:41 |
| beuno | if this is bug 288751 we're talking about, I suspect it's autopacking as well | 22:42 |
| ubottu | Launchpad bug 288751 in bzr "bzr push returns error Revision <x> not in <y>" [Critical,Triaged] https://launchpad.net/bugs/288751 | 22:42 |
| lifeless | beuno: we're talking about a cluster | 22:42 |
| thumper | abentley: I don't know if I had a bug number for this one | 22:42 |
| thumper | abentley: oh, hang on | 22:42 |
| abentley | thumper: That one ended with Revision X not present in KVF. I'm running check on my mirror of trunk. | 22:44 |
| thumper | abentley: I think it is this one: https://bugs.edge.launchpad.net/ubuntu/+source/bzr/+bug/293679 | 22:44 |
| ubottu | Launchpad bug 293679 in bzr "1.9rc1 can't push to Launchpad" [Undecided,Invalid] | 22:44 |
| thumper | abentley: bug 293679 is the one that takes ages | 22:44 |
| ubottu | Launchpad bug 293679 in bzr "1.9rc1 can't push to Launchpad" [Undecided,Invalid] https://launchpad.net/bugs/293679 | 22:44 |
| abentley | lifeless: There is also bug 295350. | 22:47 |
| ubottu | Bug 295350 on http://launchpad.net/bugs/295350 is private | 22:47 |
| abentley | lifeless: That one is a regression from 1.8, and affects HPSS only. | 22:49 |
| lifeless | ok | 22:50 |
| james_w | gmb: please run http://people.ubuntu.com/~jamesw/check-packs.py at your leisure | 22:56 |
| james_w | gmb: "python check-packs.py lp:~gmb/project/whatever-you-called-that-branch" | 22:57 |
| === kiko is now known as kiko-afk | ||
| * spiv waves | 22:59 | |
| lifeless | spiv: is the autopack verb aware of stacking? | 22:59 |
| lifeless | spiv: (does it ensure it doesn't get a parameterised repository) | 23:00 |
| spiv | thumper: pong | 23:00 |
| spiv | lifeless: Hmm. | 23:01 |
| lifeless | spiv: if its a method on repository, it should be fine, but it if opens (on the server) the repo via branch... then it won't be ;) | 23:02 |
| spiv | lifeless: the server-side simply calls repo._pack_collection.autopack() | 23:02 |
| spiv | Ok, it should be fine then. It doesn't open it via the branch. | 23:02 |
| lifeless | ok | 23:02 |
| spiv | Also, I'm not sure if the client would even invoke it for a stacked repo, the behavior of InterPackRepo.fetch probably avoids it. | 23:03 |
| lifeless | spiv: then it will autopack over the wire | 23:04 |
| spiv | Right. | 23:05 |
| thumper | spiv: can you skype quickly? | 23:09 |
| spiv | thumper: ok, just a moment. | 23:11 |
| spiv | thumper: I'll just go grab my headset | 23:12 |
| w00t_ | hi, i've got a very tricky vcs problem, and i'm wondering whether perhaps bzr can do some insane tricks to help me solve it, but i'm not sure :) does anyone have experience with messing around with imports/conversions and so on? involves subversion, and to a large extent git as well.. :P | 23:16 |
| w00t_ | essentially, i imported a damaged svn repository which i didn't have commit into git, and did lots of my own hackery, now they want to replaced their damaged svn repo with a fresh one cloned from mine.. with git, though, this will involve nuking all the historical timestamps and authors on the commits (new repo, clone with git-svn, use remotes to rebase the entire old repo onto the new svn repo & dcommit), which is horrible, and i'd like to avoid | 23:19 |
| w00t_ | (yes, I'm well aware this is insane | 23:19 |
| w00t_ | ) | 23:19 |
| lifeless | whats damaged in the repo? | 23:20 |
| w00t_ | about 200 revisions are untouchable, literally | 23:20 |
| fullermd | Well, it's in svn ;) | 23:20 |
| w00t_ | i had to import around them using git-svn | 23:21 |
| w00t_ | fullermd: definitely so. unfortunately, not everyone has seen the light yet, so I have to try work with them in a way that won't drive either of us insane :-) | 23:21 |
| lifeless | so, you could fastexport to bzr, then bzr push into a new svn repo; this will preserve timestamps and authors AFAIK | 23:22 |
| w00t_ | do you have some docs I can read? :) | 23:22 |
| lifeless | you can obviously test with a svn repo on your own machine | 23:22 |
| lifeless | install bzr-svn | 23:22 |
| lifeless | and there is the bzr svn faq and docs on the wiki | 23:22 |
| w00t_ | (this will also probably involve me learning/using bzr instead of git, which I've wanted to do for ages) | 23:22 |
| w00t_ | is 'fastexport' a bzr plugin also? | 23:23 |
| lifeless | yah | 23:23 |
| lifeless | well | 23:23 |
| lifeless | there is git-fastexport | 23:23 |
| lifeless | and bzr fastimport | 23:23 |
| w00t_ | ah | 23:23 |
| w00t_ | of course.. i'm having a blonde day! :) | 23:23 |
| lamalex | does anyone here use the emacs vc-bzr mode? | 23:26 |
| lifeless | lamalex: I think vila does | 23:26 |
| lamalex | vila: ping? | 23:27 |
| w00t_ | lifeless: bzr fast-import and bzr fastimport both don't seem to exist.. is it likely to be in some external package? (I'm using ubuntu with bzr+bzr-svn packages installed, can't see any that look relevant) | 23:27 |
| jelmer | w00t_, fastimport/fastexport != bzr-svn | 23:28 |
| * w00t_ scratches his head | 23:28 | |
| lifeless | w00t_: you need bzr-svn to push to svn, and fastimport is separate | 23:28 |
| lifeless | http://bazaar-vcs.org/BzrFastImport | 23:28 |
| w00t_ | ah! lovely | 23:28 |
| w00t_ | let me give that a whirl | 23:28 |
| vila | lamalex, sry, not vc-bzr yet :-/ | 23:32 |
| vila | lamalex, but ask your question anyway :) | 23:32 |
| lamalex | i was wondering if anyone knew the minor-mode to commit | 23:32 |
| lamalex | i can't find it lol | 23:32 |
| bob2 | what do you mean? | 23:33 |
| lamalex | so i do | 23:33 |
| bob2 | C-x v v invokes the commit editor | 23:33 |
| lamalex | M-x vc-<TAB> and nothing looks like commit | 23:33 |
| lamalex | lemme try that | 23:33 |
| lamalex | is there a guide anywhere? | 23:34 |
| bob2 | C-h i -> emacs -> version control | 23:34 |
| lamalex | oh right, emacs has help | 23:34 |
| lamalex | I'm new to emacs also | 23:34 |
| lamalex | a recent vim convert | 23:34 |
| lamalex | I LOVE it, but it's got a curve for sure | 23:34 |
| bob2 | the point of vc is that it works similarily (*) for all vc systems | 23:34 |
| bob2 | * which is not terrible useful for things other than cvs | 23:35 |
| w00t_ | lifeless: the import is running now, thanks! let's see how this goes.. so, next I guess I'll need to figure out how to use bzr-svn to push to an empty SVN repo? (or can it create one I wonder) | 23:35 |
| lifeless | w00t_: jelmer can advise better than I; but I imagine it is just (after creating the svn repo) bzr svn-push svn://path/to/repo/trunk | 23:37 |
| lifeless | w00t_: (svn-push is needed for the first push of a branch to svn) | 23:37 |
| lamalex | bob2: so it's not useful for bzr? | 23:38 |
| lamalex | i saw there was a dvc mode when i googled bzr emacs | 23:39 |
| bob2 | depends what you want to do and which version of emacs | 23:39 |
| lamalex | emacs 22.2, and basically i want to commit, and see diffs from a bzr tree | 23:41 |
| lamalex | merge | 23:41 |
| lamalex | basic vcs stuff I suppose | 23:41 |
| lamalex | but ive never used any ide+vcs before | 23:41 |
| lamalex | i usually just have two shells open | 23:41 |
| lamalex | so im intrigued by this | 23:41 |
| bob2 | iirc trying to commit multiple files in emacs 22 will do multiple commits, which is a bit useless | 23:42 |
| bob2 | merging, no idea, diffs should be fine | 23:42 |
| lamalex | meh ill just stick with the cli :( | 23:46 |
| bob2 | should be greatly improved in a recent cvs snapshot | 23:46 |
| lamalex | too bad, coulda been pretty cool | 23:46 |
| w00t_ | lifeless: hmm. I shall try that then | 23:46 |
| lamalex | bob2: in an emacs snapshot, or a vc-bzr snapshot | 23:46 |
| bob2 | lamalex: both | 23:47 |
| vila | lamalex, vc-bzr is file-oriented, dvc is tree oriented, you should try dvc | 23:48 |
| w00t_ | lifeless: ERROR: Not a branch <--- I assume that means I need to 'bzr update' like the fast-import process mentioned | 23:48 |
| lifeless | w00t_: run 'bzr branches' | 23:49 |
| w00t_ | I see all my branches listed there :) | 23:49 |
| lifeless | w00t_: the not a branch error most likely just means you are in a dir that isn't itself a branch | 23:49 |
| w00t_ | the dir it mentions as not being a branch is a subdir of my .bzr: /project/.bzr/branch/ actually | 23:50 |
| lifeless | w00t_: was 'project' listed in the output of bzr branches? | 23:50 |
| w00t_ | no, project isn't a branch name, it's the name of the project | 23:51 |
| lifeless | right | 23:51 |
| lifeless | so project isn't a branch :) | 23:51 |
| w00t_ | hmm, all bzr commands (log etc) seem to give the same error | 23:51 |
| lifeless | cd to one of your branches | 23:51 |
| w00t_ | uh | 23:51 |
| w00t_ | ...oh. | 23:52 |
| * w00t_ rm -r and reimports to remove a lot of mess from assuming that .bzr worked the same way as .git :P | 23:52 | |
| lifeless | w00t_: where git has 'refs' we have 'branches', each of which is a dir with its own tags and head; the historical data (gits 'objects') lives in .bzr/repository | 23:53 |
| * w00t_ nods | 23:53 | |
| w00t_ | I got too used to one working directory | 23:54 |
| lifeless | you probably have something like projects/.bzr/repository, and then projects/branchX/.bzr/branch | 23:54 |
| lifeless | working directories are maintained with metadata in .bzr/checkout | 23:54 |
| lamalex | vila: with dvc i still couldn't find how to commit, but I forgot about C-h | 23:54 |
| lamalex | so I'll try that | 23:54 |
| lifeless | you can mix and match these as needed | 23:54 |
| w00t_ | lifeless: hmm, that is a little confusing :) | 23:55 |
| w00t_ | I'm sure I'll get used to it | 23:55 |
| lifeless | w00t_: e.g. - git-like - bzr init-repo --no-trees .; bzr init trunk; bzr checkout --lightweight trunk working | 23:55 |
| lifeless | will give you a branch 'trunk' and a single working dir 'working' | 23:55 |
| lifeless | then bzr branch trunk feature will make a new branch feature | 23:55 |
| lifeless | and (in working) 'bzr switch feature', 'bzr switch trunk' etc etc | 23:55 |
| bob2 | lamalex: C-h m gives you help for all active minor or major modes | 23:56 |
| w00t_ | lifeless: hmm, what does the --lightweight on checkout do? | 23:56 |
| lifeless | but because these things are separate, you can decouple them further - you can have the repository on a central server, for svn-alke behaviour, or, well - there are lots of useful ways to use it | 23:56 |
| lifeless | w00t_: it just tells bzr that 'working' should not be a branch itself | 23:57 |
| w00t_ | branches and branches and branches, oh my :) | 23:57 |
| lifeless | w00t_: 'bzr checkout foo bar' will create a branch of foo in bar, and 'bind' it to foo, so that commits to bar are immediately pushed to foo | 23:57 |
| vila | lamalex, once you have a dvc-diff or dvc-status buffer commit is 'c' | 23:58 |
| lifeless | w00t_: --lightweight is useful when both foo and bar are local, because you don't need a spare copy of the history | 23:58 |
| lifeless | w00t_: if foo was on a remote server, you'd want a mirror of the history for performance | 23:58 |
| w00t_ | that is really quite nifty for tossaway branches that you want to share commits with another branch | 23:58 |
| w00t_ | does unbind (and a bunch of commits) and a later re-bind push those commits to the origin? | 23:59 |
| lifeless | bind won't immediately push | 23:59 |
| w00t_ | hm | 23:59 |
| lifeless | it might not be able to if someone else has pushed to the origin | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!