| tsmithe | strangely, using open_tree_or_branch to simultaneously do the opening doesn't seem to help, and _filter... seems to depend heavily on already knowing the revision id. it seems a lot easier to do this using pysvn, but i suppose that may be because pysvn is an extra abstraction layer.. (and that doesn't help me as i'm using bzr) | 00:07 |
|---|---|---|
| tsmithe | garyvdm: ^ | 00:07 |
| garyvdm | Yes | 00:08 |
| garyvdm | Give me a sec | 00:08 |
| tsmithe | no problem | 00:08 |
| lifeless | awilkins: pong | 00:19 |
| garyvdm | tsmithe: http://pastebin.com/m4e620ab5 | 00:26 |
| tsmithe | garyvdm: thanks - that didn't work when (as i was doing) i was opening the tree/branch with path "..". however, when i changed to ".", your code worked - so thank you. but that made me wonder whether find_touching_revisions would work in ".". it did. curious. | 00:38 |
| Peng_ | Hmm, Loggerhead is using more RAM than usual. | 01:27 |
| GungaJin | What does '.. will create a repository within the new branch' mean? Aren't branches supposed to be stored IN repositories? | 01:36 |
| mwhudson | Peng_: well i don't think _i've_ committed any code for weeks :) | 01:37 |
| SamB | GungaJin: I think it means it will put the repository in the .bzr directory that is inside the branch's working directory | 01:38 |
| GungaJin | man... it's so confusing that each vcs uses slightly different meanings for the same term... | 01:39 |
| SamB | I'm not saying that that's the right way for it to say that ... | 01:39 |
| SamB | just that that's probably what was meant | 01:39 |
| dash | GungaJin: if they didn't, they'd be the same vcs probably :) | 01:40 |
| GungaJin | well, it also says that 'bzr init' makes a directory a versioned branch... | 01:40 |
| GungaJin | dash - not necessarily :) | 01:40 |
| SamB | could make up new terms | 01:40 |
| SamB | or take them all from monty python and red dwarf | 01:41 |
| GungaJin | :) | 01:41 |
| mwhudson | are you storing your gumby in a shared grail? | 01:42 |
| Peng_ | You know what's smart? Walking thousands of directories, 3 times. :X | 01:52 |
| Peng_ | mwhudson: Yeah, you're probably right. :P Let's blame jelmer, since he's not here! :) | 01:53 |
| poolie | hello all | 01:54 |
| spiv | poolie: hello! | 01:55 |
| garyvdm | zzzz - time for bed | 01:57 |
| poolie | jml: re review mail, why not open a bug and post the link to the list | 02:41 |
| poolie | then maybe once you know, summarize what can be done | 02:41 |
| poolie | as a workaround, if anything | 02:41 |
| jam | jml: Is 'launchpad' or 'launchpad-code' the right place to submit 'code review' bugs? | 02:56 |
| lifeless | lp-code | 02:56 |
| igc | morning poolie, jam, all | 02:56 |
| lifeless | hi igc | 02:56 |
| igc | morning lifeless, spiv | 02:56 |
| jam | lifeless: k, launchpad has the tag 'code-review', but I can migrate my bugs as appropriate | 02:56 |
| jam | morning igc | 02:57 |
| igc | hi jam - really well done of the bencode stuff | 02:57 |
| jam | igc: thanks. Now if I can just get the patch to land :) | 02:57 |
| jam | Just silly things like having an old GPL header | 02:58 |
| jam | or Revision.parent_ids wanting to be a 'list' rather than a 'tuple' | 02:58 |
| igc | jam: :-) | 02:59 |
| jml | jam: launchpad-code also has the tag code-review | 03:00 |
| jml | jam: in any event, you can *always* file bugs on 'launchpad'. matsubara or Ursinha will look at it, triage it & assign to the right subproject. | 03:01 |
| poolie | hello igc! | 03:01 |
| poolie | hello lifeless | 03:01 |
| spiv | igc: Morning, I just reviewed your dirstate patch as it happens :) | 03:02 |
| igc | hi spiv, just readng over your comments now | 03:02 |
| igc | so spiv, a few things ... | 03:03 |
| igc | I did really mean "is not False" - the attribute is tristate ... | 03:04 |
| igc | where None means not yet set and False means "don't allow setting to True" | 03:04 |
| GungaJin | How can I list all revisions on a branch? | 03:05 |
| spiv | igc: hmm | 03:05 |
| igc | spiv: and some low level dirstate tests do fail from memory if the limit is non-zero | 03:05 |
| spiv | igc: I get that it's a tristate, but in that case wouldn't "is None" fit better? | 03:05 |
| igc | I think they make changes and explicitly go and read the file content, or something like that | 03:06 |
| spiv | igc: because setting to True when already True is pointless | 03:06 |
| jam | spiv: thanks for all your reviews | 03:06 |
| igc | spiv: is None would be better | 03:06 |
| spiv | If it wasn't used in so few places and in such performance critical code I would've suggested using more explicit symbols for the tristate enum... True/False/None isn't a great fit. | 03:07 |
| igc | spiv: I did benchmark keeping the lines around at the beginning, at least in Python code (my pyrex sucks) | 03:08 |
| lifeless | dirstate code is fixable now | 03:08 |
| lifeless | as we have a C version and a python version | 03:08 |
| lifeless | if something canbe cleaner, just make sure that part has a pyrex version, and make the python one as clean as you like | 03:09 |
| igc | spiv: it's faster not to do anything unless it's really needed, i.e. leave the reading until we know we need to do it | 03:09 |
| poolie | jam: does your custom decoder try using a list rather than a dict? | 03:09 |
| lifeless | and the pyrex version can be plan C | 03:09 |
| poolie | if you did, it'd be getting fairly close to the minimal bytes, i think | 03:09 |
| jam | poolie: The format change I made uses a list | 03:09 |
| jam | the custom decoder doesn't use either | 03:10 |
| jam | it just sets attributes on self | 03:10 |
| jam | and then passes those to a Revision object | 03:10 |
| igc | spiv: so my plan was to left the reading until just before we know we're about to make a batch of changes, say | 03:10 |
| spiv | igc: fair enough (regarding keeping the lines), it might be worth a brief comment where you re-read them mentioning that, because it's a little counter-intuitive that repeating work is cheaper. | 03:11 |
| poolie | i meant a bencode list, like l12:mbp@sourcefrog23:mbp@123g131983712983719837e | 03:11 |
| jam | The pyrex bencode just uses whatever you told it to. The "lp:~jameinel/bzr/revision_bencode_decoder" is a more stateful "if key == 'message': self.message = self._read_string()" sort of thing. | 03:11 |
| igc | spiv: either way, the current patch is a pretty nice performance improvement and the other smarts can come when I tune commit and other operations later | 03:11 |
| igc | spiv: yes, good pointy | 03:11 |
| igc | s/pointy/point/ | 03:12 |
| jam | poolie: Right, so the new disk format is a list of 2-entry lists | 03:12 |
| jam | rather than a dict | 03:12 |
| jfroy | how do I set the working tree of a branch (in my case a lightweight checkout of a local branch) to a specific revision? | 03:12 |
| spiv | jam: Of [['revid', 'foo@bar-123'], ['author', 'Joe Example <...>'], ...] ? | 03:12 |
| jam | jfroy: bzr remove-tree; bzr co -r X ? | 03:13 |
| jam | spiv: basically | 03:13 |
| spiv | jam: IIRC poolie's suggestion was to do away with the key-name elem entirely for the fields that are always present. | 03:13 |
| jfroy | jam: what, you have top delete the tree? | 03:13 |
| jfroy | there's no equivalent to svn up -r foo | 03:13 |
| jfroy | *have to | 03:13 |
| spiv | jam: so ['foo@bzr-123', 'Joe Example <...>', ...] for that example | 03:13 |
| jam | jfroy: https://code.edge.launchpad.net/~mhammond/bzr/update-r/+merge/6980 | 03:14 |
| spiv | jam: which makes sense to me; even though the repeated parts should compress wonderfully it's still less raw text to validate when decoding. | 03:14 |
| jam | spiv, poolie: So I think we can consider it. | 03:14 |
| jam | I kind of like self | 03:14 |
| jam | self-describing disk formats | 03:14 |
| jam | when possible | 03:14 |
| jam | also, it gives me *some* flexibility to change the order if we find something better | 03:15 |
| jam | without completely nuking the reader | 03:15 |
| jam | though... if we consider the exact bytes to be sanctified, then we'd have to be careful | 03:15 |
| lifeless | jam - your read vs readlines tests | 03:19 |
| lifeless | jam: are they done on many small files, or one huge one? | 03:19 |
| jam | lifeless: that test is on one huge one | 03:19 |
| jam | the memory consumption is about how many X we are of the largest file | 03:19 |
| jfroy | bahamut$ bzr co -r 769 --lightweight carrier/ carrier-769 | 03:19 |
| jfroy | bahamut$ bzr revno carrier-769/ | 03:19 |
| jfroy | 794 <-- :( | 03:19 |
| lifeless | jam: I think that test is not representative then. Because we can't really scale up that way anyhow. | 03:19 |
| jam | we are pretty good about not holding the content of all files the whole time during commit | 03:19 |
| lifeless | I'm about to mail a large file support proposal to the list | 03:20 |
| lifeless | would appreciate your critique of it | 03:20 |
| jam | lifeless: well, *today* we have about 5x memory overhead for committing the content of a no-eol file | 03:20 |
| jam | so a 100MB file => 500MB during commit | 03:20 |
| lifeless | jam: yes | 03:20 |
| lifeless | and your work is key to making that tolerable | 03:20 |
| jfroy | jam: fixing that issue would be awesome | 03:20 |
| Peng_ | I think Loggerhead is leaking bzr-svn-related things. | 03:20 |
| jfroy | I have a few branches that take GBs of real RAM to check out. | 03:21 |
| jam | jfroy: I have 2 patches up, which bring it down to 2x for --dev6 formats | 03:21 |
| jam | jfroy: checkout != commit | 03:21 |
| jfroy | oh? revno gives the tip revno all the time? | 03:21 |
| jam | jfroy: 'bzr revno' is the branch revno, IIRC | 03:21 |
| jam | not the WT revno | 03:21 |
| jfroy | that's correct :| | 03:22 |
| jfroy | "This is equal to the number of revisions on this branch" | 03:22 |
| jfroy | soooo | 03:22 |
| jfroy | bzr st says 'working tree is out of date, run 'bzr update'' | 03:22 |
| jfroy | bzr info says nothing | 03:22 |
| jfroy | ahhh | 03:23 |
| fullermd | Surely there's a better way to get a Revision from a revid than doing RevisionSpec.from_string('revid:' + revid), right? | 03:23 |
| jfroy | version-info | 03:23 |
| jfroy | completely unintuitive name | 03:23 |
| jfroy | that command fails | 03:23 |
| jfroy | I mean, it's name is a fail | 03:23 |
| spiv | fullermd: repo.get_revision(revid) | 03:24 |
| fullermd | I can get the repo from a Branch object, right? | 03:24 |
| fullermd | jfroy: How funny that you're grumpy about revno right at this moment... | 03:25 |
| spiv | branch_obj.repository, yeah :) | 03:25 |
| fullermd | Oh, heck, it wants a RevisionSpec... | 03:30 |
| * fullermd gets grumpy. | 03:30 | |
| fullermd | Oh well. Silliness it is then. | 03:32 |
| Peng_ | Loading an 8 MB Dozer page is definitelt a good idea. | 03:38 |
| Peng_ | Such a good idea that I can't spell it! | 03:38 |
| thumper | fullermd: why not repository.get_revision(revid) | 03:39 |
| fullermd | Because I need a RevisionSpec, not Revision. | 03:40 |
| * thumper sees spiv's response | 03:40 | |
| thumper | fullermd: for what? | 03:40 |
| fullermd | Bah, send -o doesn't expand ~. Hrmph. | 03:40 |
| jam | fullermd: "bzr send -o ~foo" would be expanded by the shell, wouldn't it ? | 03:41 |
| fullermd | Probably, but -o~foo isn't. | 03:41 |
| jam | I suppose -o~foo might not | 03:41 |
| fullermd | thumper: for https://lists.ubuntu.com/archives/bazaar/2009q2/059119.html | 03:44 |
| fullermd | jfroy: See ^^ | 03:46 |
| spiv | fullermd: I wonder what happens if the current revid no longer exists on branch (e.g. make a lightweight checkout, then someone else uncommits the tip, then you try "bzr revno --tree" in the checkout)? | 03:47 |
| jfroy | fullermd: eh | 03:47 |
| jfroy | good enough | 03:47 |
| jfroy | fullermd: you could add a "--both" flag | 03:47 |
| jfroy | which would be suitable for an alias | 03:47 |
| jfroy | like "revnoa" or whatever | 03:48 |
| jfroy | (a -> all) | 03:48 |
| fullermd | spiv: Not sure. revision-info blows up in such cases... | 03:48 |
| Pegasus_RPGAMD64 | hello. If I've checked out a branch anonymously, what's the command to authenticate so I can check in? | 03:48 |
| fullermd | jfroy: Well, _you_ could. I just blew my bzr time for the rest of the month on that :p | 03:48 |
| spiv | fullermd: I'm not surprised... | 03:49 |
| fullermd | Presumably version-info should grow something similar too... | 03:51 |
| fullermd | Actually, version-info probably should DEFAULT to the tree rev, considering its aim. | 03:51 |
| spiv | fullermd: makes sense to me, but I probably lean towards making revno and revision-info default to the tree rev too... | 03:53 |
| fullermd | I wouldn't argue against that. | 03:53 |
| fullermd | Having the option at least cuts down on my grumpiness a bit anyway. | 03:55 |
| * igc lunch | 04:04 | |
| * spiv -> food, etc | 04:04 | |
| * spiv hopes this vicious sore throat goes away soon | 04:04 | |
| Pegasus_RPGAMD64 | oh found it...bzr bind bzr+ssh://... | 04:08 |
| Peng_ | mwhudson: ping | 04:38 |
| Peng_ | Actually, I don't really need to ping you. | 04:39 |
| jml | poolie: you available for a bzr related call? | 04:39 |
| mwhudson | Peng_: :) | 04:46 |
| Peng_ | mwhudson: Running Dozer is fun! Especially the 20 MB page listing all of the lists! :D | 04:48 |
| Peng_ | Loggerhead seems to be leaking some bzr-svn-related stuff. | 04:49 |
| Peng_ | From when it scans the directories for branches. | 04:49 |
| mwhudson | that sounds vaguely familiar | 04:52 |
| Peng_ | Yeah, it does. | 04:52 |
| mwhudson | also, i'm tempted to say, NFM | 04:52 |
| mwhudson | NMF | 04:53 |
| Peng_ | NMF? | 04:53 |
| Peng_ | Oh. | 04:53 |
| Peng_ | :D | 04:53 |
| Peng_ | If one of you enjoys looking at Dozer output for some strange reason, http://bzr.mattnordhoff.com/loggerhead/_dozer/index :D | 04:53 |
| Peng_ | A few hundred subversion-related things shouldn't account for much RAM, should it? | 05:00 |
| mwhudson | depends what the things are, but no, not really | 05:10 |
| mwhudson | Peng_: have you seen jam's py_mem_profile thingy? | 05:10 |
| Peng_ | mwhudson: SubversionAuthenticationConfig and SubversionException, FWIW. | 05:12 |
| mwhudson | Peng_: those sound small indeed | 05:13 |
| Peng_ | mwhudson: I might've read the email, but normally I'm not interested in memory profiling, so I don't remember it. | 05:13 |
| Peng_ | Eh, I think the garbage collector keeps doing its job, making it difficult to analyze this. :P | 05:16 |
| Peng_ | Anyway! | 05:17 |
| jml | spiv: thanks! | 05:25 |
| spiv | jml: np | 05:25 |
| spiv | jml: (although I'm not sure if my commit rights are adequate to land something on bzr.1.15, but I guess we'll find out soon...) | 05:34 |
| jml | :D | 05:34 |
| poolie | spiv, i think i asked spm to make access to all branches the same | 05:37 |
| poolie | at any rate i don't see much value in having different privilege levels | 05:37 |
| spm | spiv: poolie: we have 2 groups: bzr and bzr-release-mgr. bzr can ci to trunk; release manager to the versioned branches. aiui, it's been that way for a long time. it may be worth collapsing those to a single group? and/or revisiting the membership? | 05:44 |
| spiv | spm: I think it's probably ok to let any committers commit to all branches, but poolie gets the final say. | 05:46 |
| spm | spiv: given the trivial diff on those two groups? I'd agree; but as you say :-) | 05:47 |
| spiv | For me the convenience of allowing a dev to cherrypick and land their own fix probably outweighs the "only RMs are fully trustworthy" paranoia. | 05:47 |
| spiv | And yeah, given that most devs have also been RMs at some point I'd expect the difference between the two groups to be minimal (and confusing) | 05:48 |
| spiv | jml: (it looks like PQM likes me) | 05:53 |
| lifeless | there are only two groups because when I asked martin 'who do you want to be able to commit to <first release branch> he named a subset | 06:01 |
| lifeless | its trivial to make it just one group | 06:01 |
| jml | spiv: :) | 06:04 |
| Peng_ | So...the bencode repo format had worse performance than RIO, right? Why was it chosen? | 06:12 |
| lifeless | igc: your dirstate patch | 06:12 |
| igc | hi lifeless | 06:13 |
| lifeless | igc: does it actually make saving faster, or does it just save under less circumstances, or both ? | 06:13 |
| igc | both | 06:13 |
| lifeless | cool | 06:13 |
| lifeless | did my suggestion make sense? | 06:13 |
| igc | yes, I'd liked it and it would be enough for status | 06:13 |
| igc | i.e. for faster status | 06:13 |
| lifeless | now | 06:14 |
| lifeless | I have a planned change to dirstate | 06:14 |
| lifeless | for windows | 06:14 |
| lifeless | that will interact, do you have a minute to chat regarding this | 06:14 |
| igc | sure | 06:14 |
| lifeless | so to meet the dual constraints of windows fs limitations and bisection (for insanely fast 'st foo') I've proposed removing the single dirstate file | 06:15 |
| lifeless | instead have a current pointer | 06:15 |
| lifeless | and a directory of dirstates | 06:15 |
| igc | ok | 06:16 |
| lifeless | so we'll write to a new file when we do an update | 06:16 |
| lifeless | and then link it into current, try to remove the stale one and if that fails assume another process is currently using it | 06:16 |
| igc | don't we write the lot out again anyhow now? | 06:16 |
| lifeless | yes | 06:17 |
| lifeless | a related but more complex change we could make | 06:17 |
| lifeless | is to go to some sort of journalling system | 06:17 |
| lifeless | I don't think we have the time to do that for 2.0 | 06:17 |
| lifeless | but we do, if we focus, to do the simpler change of having a current pointer and many full dirstates | 06:18 |
| lifeless | it may be that this doesn't really interact with your code at all; in which case cool | 06:19 |
| lifeless | but I thought it was worth running it up the flagpole | 06:19 |
| igc | lifeless: I think my change is independent and won't clash in any way | 06:20 |
| lifeless | cool | 06:21 |
| * spiv -> giving up for the day. Have a good weekend everyone. I should be over ubuflu by next week :) | 06:29 | |
| jfroy | bah! | 06:39 |
| jfroy | cherrypicking is maddening | 06:39 |
| jfroy | is there a revspec to specify "revision xyz up to tip of target branch"? | 06:39 |
| jfroy | -r xyz.. does... bad things | 06:39 |
| lifeless | jfroy: that should work fine; can you expand on bad? | 06:40 |
| jfroy | it goes crazy and conflicts to all hell | 06:41 |
| jfroy | I just want to merge the last 2 revision of A into B (A was branched from B) | 06:41 |
| lifeless | well, its possible that the conflicts are genuine | 06:42 |
| lifeless | do you get them if you apply the revisions as plain patches, or something similar? | 06:42 |
| jfroy | No, there's no way those 2 revisions would conflict. | 06:43 |
| jfroy | And not in the manner it's doing. | 06:43 |
| jfroy | I'm getting content conflicts, file deletes and renames. | 06:43 |
| jfroy | Those 2 revisions are simple edits to a few files. | 06:43 |
| lifeless | sounds like the files were added independently to A and B | 06:43 |
| lifeless | so bzr thinks they are different files that happen to be at the same path | 06:44 |
| jfroy | B was branched from A. | 06:44 |
| jfroy | and has 5 revisions more than A. | 06:44 |
| jfroy | I want to bring the last 2 into A. | 06:44 |
| jfroy | (skipping over the first 3) | 06:44 |
| lifeless | I get that from your prior explanation. However, if you are getting content conflicts it [insert my 'sounds like' above] | 06:45 |
| lifeless | spiv: you should be able to use pqm with lp branches now | 06:46 |
| fullermd | A quick way to verify that it's not the .. would be to cherrypick the revs individually and see what you end up with. | 06:46 |
| lifeless | jfroy: you can use 'bzr inventory --show-ids' to debug this | 06:46 |
| jfroy | I'm pretty sure I'm just being stupid | 06:46 |
| jfroy | with the merge command | 06:46 |
| jfroy | and not understanding revspecs :/ | 06:46 |
| lifeless | jfroy: no, I think its something else. Humour me. | 06:47 |
| jfroy | yeah, doing two merge with -c x and -c y worked fine | 06:51 |
| jfroy | (where x < y and {x, y} are the last 2 revisions of the merged branch) | 06:52 |
| lifeless | jfroy: ok, please file a bug | 06:52 |
| jfroy | so, should merge -r x.. do the same merge> | 06:52 |
| jfroy | *? | 06:52 |
| lifeless | roughly | 06:53 |
| lifeless | uhm, it won't include x | 06:53 |
| lifeless | merge -r {x-1}.. | 06:53 |
| lifeless | the range x-1..x == -c x | 06:54 |
| jfroy | yeah, that has a completely different outcome | 06:54 |
| jfroy | whoa | 06:55 |
| jfroy | revision_id = _mod_revision.ensure_null(revision_id) | 06:55 |
| jfroy | ... | 06:55 |
| jfroy | thank you IRC | 06:55 |
| jfroy | bzrlib/repository.py:2308: DeprecationWarning: NULL_REVISION should be used for the null revision instead of None, as of bzr 0.91. | 06:55 |
| jfroy | revision_id = _mod_revision.ensure_null(revision_id) | 06:55 |
| jfroy | the merge basically deletes most of the files in the branch | 06:55 |
| jfroy | however, -r (x-1)..y works fine | 06:57 |
| lifeless | jfroy: definitely file a bug | 06:58 |
| jfroy | will do | 06:59 |
| lifeless | poolie: so 2.0 | 07:19 |
| lifeless | poolie: I agree we need eye on the prize; heck I've been chanting that mantra | 07:19 |
| vila | hi all | 07:19 |
| lifeless | poolie: but the total lockdown on formats (thanks jml btw, I hear thats your idea) means there will be an awful long time before things we fix shortly after are made available to users. | 07:19 |
| poolie | hello vila! | 07:20 |
| poolie | lifeless: let's not overcatastrophize the format thing | 07:21 |
| lifeless | hi vila | 07:21 |
| poolie | it's been a mess, it needs to be better, but we don't need to do anything stupid to just have less active formats | 07:21 |
| lifeless | poolie: I don't mean to. Its unclear what we're signing up for is all; I know I'm not alone expressing concerns here. | 07:21 |
| poolie | ok | 07:22 |
| poolie | noted | 07:22 |
| poolie | i have a sinking feeling about answering that mail on the list because it may cause a lot of partly-constructive chatter about the best way to develop software in general | 07:22 |
| vila | igc: I have some troubles with usertest: 1) selftest is not passing, 2) I get http://paste.ubuntu.com/188798/ | 07:22 |
| fullermd | Obviously, the best way to develop software in general is to use bzr 8-} | 07:23 |
| lifeless | actually, ignore my concerns here. Mark asked for one format in 3.0 | 07:23 |
| lifeless | poolie: and sure, we need to batch things up into larger amounts, get more network independence etc. | 07:24 |
| lifeless | ok, I'm going to halt() now | 07:25 |
| poolie | i guess briefly i see it as being a lot like an individual release | 07:25 |
| lifeless | still somewhat sinusy but nearly well | 07:25 |
| poolie | i'd desperately like to fix all the things you name | 07:25 |
| poolie | but should we slip 1.16 til they're done? probably not, there's good stuff to get out | 07:26 |
| lifeless | poolie: marks mail, april 16th or so 'scoping the ui...' talks about 3.x | 07:26 |
| lifeless | poolie: I had confabulated that to be 2.x in my head | 07:26 |
| lifeless | in 2.x we should do better than we have with plethora-of-formats | 07:26 |
| poolie | i said the same thing to him, that though i'd love to do them we need to get 2.0 out | 07:26 |
| lifeless | in 3x we're being asked to have one format for the life of the 3.x series | 07:26 |
| fullermd | Just killing off poor roots takes care of probably 75% of that right there... | 07:27 |
| poolie | the main point is: there should be a clear moment at which we have a new format and migrate people on to it | 07:27 |
| poolie | we should not do it every two months, but if it turns out that by the end of 2009 say we have great new work that requires a new format i'm happy to call that 3.0 | 07:28 |
| poolie | i guess the secondary point is: somewhat larger steps, rather than dribs and drabs | 07:28 |
| poolie | but that can be guided by experience | 07:28 |
| h6w | Hey, what should I use to provide public access to my bzr+ssh repos? For our svn repos we used the subversion apache module. Is there one for bzr, too? | 07:29 |
| vila | poolie: which is the whole point IMHO. That mail doesn't seem to take into account many decisions, already agreed upon by the team, but maybe not visible enough yet. | 07:30 |
| vila | i.e. we don't want to get into rich-root/non-rich-root divergence ever again | 07:31 |
| vila | for example | 07:31 |
| lifeless | poolie: so what I'm saying is broadly 'yes', but that 3.x should be more guided by 'we think we have a <good period> of breathing room', and that during 2.x we can issue new formats still | 07:31 |
| lifeless | poolie: [if we feel the tradeoffs are worth making] | 07:31 |
| vila | lifeless: +1 | 07:31 |
| vila | forbiding experiments is definitely counter-productive (as long as they don't make our users cry) | 07:32 |
| lifeless | vila: I don't think anyone is suggesting forbidding experiments | 07:33 |
| vila | a single dev format may restrict them a lot | 07:33 |
| lifeless | vila: I don't think so; we should do them outside of core until we are fairly convinced, then roll them into the dev format. | 07:34 |
| lifeless | vila: this is a constraint for 3.x; so we should get comfortable with it during 2.x | 07:34 |
| vila | lifeless: outside of core as much as possible, I agree with that, I'm not sure *what* territory is covered by that though | 07:35 |
| lifeless | vila: My feeling is that its tied to the size and scope of the change. | 07:35 |
| lifeless | tweaking an API - short lived branch. | 07:35 |
| === thekorn_ is now known as thekorn | ||
| lifeless | changing how big files are stored - plugin or long lived loom with the bits that we're sure of merged | 07:37 |
| vila | I'm thinking about ubuntu as a branch and all installed packages as subtrees. status (implicit or explicit) may become to slow if recursion is on by default. That kind of problem is likely to have a lot of deep implications, to the point we may want to introduce some index (a la git), | 07:38 |
| vila | now, we can introduce hooks where needed and still be able to do that from a plugin, but I don't think that will make it easier | 07:39 |
| vila | s/to slow/too slow/ of course | 07:39 |
| awilkins | lifeless: Did you read my post to the list about pbranches style branch management? Do you think it's feasible? | 07:41 |
| lifeless | vila: so I think there are two things there; I've argued for a long time that working from '.' by default would be better. Anyhow if you have ubuntu in a single huge tree, status from . would be doable quickly via dirstate bisection | 07:41 |
| lifeless | vila: separately, there is 'what is involved in doing status across subtrees'. | 07:42 |
| vila | I was thinking about scanning the whole tree to update the dirstate with a tree that will trash the cache | 07:43 |
| lifeless | vila: bzr status main/coreutils would only scan main/coreutils in the cache | 07:43 |
| lifeless | and probably not pass the threshold to trigger a save | 07:43 |
| lifeless | vila: and with subtrees coreutils would be a separate tree anyhow | 07:43 |
| lifeless | vila: so there are two separate places we'd be listing all the subtrees: | 07:44 |
| lifeless | a) dirstate | 07:44 |
| lifeless | b) repository | 07:44 |
| lifeless | they have different IO/compression needs. But nevertheless, what do you think we'd need to index? | 07:44 |
| lifeless | awilkins: I saw it, haven't absorbed it. I think loom is not finished. | 07:45 |
| lifeless | awilkins: and that many issues related to it are due to it not being finished, not due to the design. | 07:45 |
| lifeless | awilkins: and further to that, that the design likely needs improving. | 07:45 |
| vila | We tend to encourage a model where the user relies on bzr to check that it doesn't forget a modification when committing. So at some points, scanning the whole tree is required. We may transfer part of that check responsability to the user so that he decides to avoid scanning the subtrees | 07:46 |
| lifeless | awilkins: I'm not at all convinced that heuristic full-topological support is good or needed. I think its hugely complex. | 07:46 |
| lifeless | vila: abentley describes this as 'recursing upwards' in the nested tree docs. | 07:46 |
| lifeless | vila: deciding whether in coreutils needs to go upwards *could* be policy. Or it could just never do it. | 07:47 |
| vila | recursing upwards sounds evil to me, but I see where it can help here... | 07:47 |
| lifeless | vila: so to commit a snapshot of all of ubuntu you'd explicitly cd to the root and commit | 07:47 |
| vila | lifeless: got it | 07:47 |
| lifeless | vila: [oh, and commit --norecurse or whatever would then just grab the last revid from subtrees rather than tryin to commit in them] | 07:59 |
| * lifeless halts() for real | 08:00 | |
| vila | lifeless: that's evil too :-) | 08:01 |
| vila | but a strange idea just came up: I think file system should handled a 'last modification date' for the tree (as opposed to the dir), but I don't hold my breath about that. Yet, that's basically what we need, so how about creating/deleting a file in the top level directory when we update the dirstate and use that as an hint ? | 08:03 |
| vila | That's not perfect, but that will curely covers many needs... | 08:04 |
| poolie | i really want to talk about the format thing but my batteries are going flat | 08:33 |
| vila | poolie: plug yourself ! Enjoy your week-end :) | 08:38 |
| jml | btw, | 08:38 |
| jml | some people were asking a while ago about how to tell Launchpad to mirror a branch right away | 08:38 |
| jml | http://paste.ubuntu.com/188831/ sketches out how to do that. | 08:38 |
| fullermd | If you stay half-asleep all the time, is that like float-charging your batteries? | 08:39 |
| jml | it relies on a branch of launchpadlib that I've written. | 08:39 |
| vila | fullermd: staying half-awake all the time is very bad for battery life, go get some sleep :-) | 08:40 |
| fullermd | I can't! All the Canonical people are still oversleeping from ubuflu, so I'm stuck on short-time to keep the balance :( | 08:41 |
| vila | fullermd: it's ok, I catched up from ubuflu, I'll take care of the balance :) | 08:42 |
| awilkins | ubuflu? Sounds like a disease that afflicts the dog that appeared at the end of the A-Team | 08:42 |
| awilkins | "Sit Ubu, sit!" | 08:42 |
| fullermd | I pity the flu. | 08:42 |
| poolie | night all | 08:44 |
| igc | night all | 09:25 |
| Peng_ | igc: Good night. | 09:25 |
| * fullermd thinks that's quite enough hackage for one night... | 10:20 | |
| fullermd | Hm. I have selftest failures... | 10:27 |
| fullermd | test_two_files_different_versions_no_inconsistencies_bug_165071 fails for me on RepositoryFormat's 5, 6, and 7. | 10:28 |
| wam | Hi, can I checkout all branches in a repo easily? | 10:59 |
| bob2 | not really | 10:59 |
| jpds | wam: You mean all branches in a code.launchpad.net team's page? | 11:01 |
| wam | so if you have a repo with several branches and want them all on your local dev folder too, do you just create a folder and co all branches seperately or do you bzr init-repo instead of mkdir? | 11:01 |
| wam | jpds: don't know - I just have a repo with some branches and would like to checkout them all | 11:01 |
| awilkins | You should init-repo | 11:02 |
| wam | ok | 11:02 |
| awilkins | Otherwise you will waste a lot of bandwidth | 11:02 |
| === arjenAU2 is now known as arjenAU | ||
| bob2 | if they are related | 11:02 |
| bob2 | (as in branches of each other) | 11:02 |
| wam | awilkins: ack | 11:02 |
| === Kissaki^0ff is now known as Kissaki | ||
| === Kissaki is now known as Kissaki^0ff | ||
| === statik` is now known as statik | ||
| vadi2 | jelmer: I've done svn-import on the svn repository on the server now, but it is complaining that what it got is not a branch: http://paste.pocoo.org/show/121138/ | 12:38 |
| === mrevell is now known as mrevell-lunch | ||
| RockyRoad | Hi :) | 12:45 |
| jelmer | vadi2: That's right, it would have imported several branches | 12:45 |
| jelmer | vadi2: they're subdirectories of yorba4/ | 12:45 |
| vadi2 | ah. | 12:45 |
| RockyRoad | Would there be a way to set the "ancestor" of a branch, in order to do some later merges ? | 12:46 |
| RockyRoad | My problem is somewhat similar to http://fourkitchens.com/blog/2009/01/19/creating-common-branch-ancestry-hard-problem | 12:47 |
| RockyRoad | I'm pretty new to bzr but I'm trying to manually rebuild a project history from { CVS, then BZR }, to BZR. | 12:48 |
| RockyRoad | I finished the CVS part, in a new project, call it B, at rev 10. | 12:48 |
| RockyRoad | The project contents at B rev 10 is identical to initial commit of project A. | 12:48 |
| RockyRoad | I pushed a copy of previous branches, in project A into project B, branch B.A . | 12:48 |
| RockyRoad | Now the problem is that I can't merge any revision of B.A into B.trunk, bzr tells me: ERROR: Branches have no common ancestor, and no merge base revision was specified. | 12:48 |
| RockyRoad | I could do "bzr merge -r 1..2 lp:branchB.A" | 12:48 |
| RockyRoad | there were conflicts, but I could resolve and commit. | 12:48 |
| RockyRoad | but the problem remains for later merges, the branches are still not linked. | 12:48 |
| jelmer | RockyRoad: I think you'd want -r0..2 | 12:49 |
| jelmer | what you were diong was a cherrypick, and bzr doesn't track cherrypicks yet, only "full" merges | 12:49 |
| RockyRoad | jelmer: thanks, I didn't try that yet | 12:50 |
| RockyRoad | 0..1 would work also ? | 12:50 |
| RockyRoad | mmm there's something strange with revert | 12:52 |
| RockyRoad | it modifies the files, and lets the revno unchanged | 12:52 |
| RockyRoad | then a commit increases revno | 12:52 |
| jelmer | RockyRoad: yes, that's intentional | 12:52 |
| vadi2 | jelmer: thank you! | 12:52 |
| RockyRoad | jelmer: no way to go back ( I've pushed it to lp also :( ) | 12:54 |
| RockyRoad | ? | 12:54 |
| RockyRoad | I tried uncommit earlier, and it doesn't work | 12:56 |
| Peng_ | jelmer: ping | 12:56 |
| jelmer | Peng_: pong | 12:57 |
| jelmer | RockyRoad: uncommit should take you back | 12:58 |
| Peng_ | jelmer: Hi. :) Um, I'm kind of sleepy, but earlier I noticed that Loggerhead is leaking SubversionException and SubversionAuthenticationConfig/ | 12:58 |
| RockyRoad | sorry to bother you with what you probably think basic | 12:58 |
| Peng_ | jelmer: (Seemingly from the code that scans directories for branches.) | 12:59 |
| Peng_ | Or something. | 12:59 |
| RockyRoad | oh ... that's a "bzr revert" I need after uncommit ! | 13:01 |
| jelmer | Peng_: please file a bug | 13:01 |
| jelmer | Peng_: leaking in what sense, btw ? | 13:02 |
| Peng_ | jelmer: Against which project? | 13:02 |
| RockyRoad | the bzr pull "tip" confused me .... | 13:02 |
| Peng_ | jelmer: In the sense that it's the only suspicious thing I found in Dozer. | 13:02 |
| jelmer | Peng_: depends, what sort of leaking is happening? | 13:03 |
| Peng_ | jelmer: I don't know. I'm dumb. But an ever-increasing number of them, currently 652, can't be good. | 13:04 |
| Peng_ | Hmm, I think it was 673 earlier. | 13:04 |
| jelmer | Peng_: how are you seeing this? | 13:04 |
| Peng_ | jelmer: Dozer. | 13:05 |
| Peng_ | Oh, 832. | 13:05 |
| Peng_ | jelmer: http://bzr.mattnordhoff.com/loggerhead/_dozer/index | 13:05 |
| RockyRoad | to resolve conflicts I need to specify each filename, is it normal ? | 13:07 |
| Peng_ | http://bzr.mattnordhoff.com/loggerhead/_dozer/trace/bzrlib.plugins.svn.auth.SubversionAuthenticationConfig http://bzr.mattnordhoff.com/loggerhead/_dozer/trace/subvertpy.SubversionException | 13:07 |
| jelmer | RockyRoad: you can also use "bzr resolved --all" | 13:10 |
| Peng_ | I thought --all was the default. | 13:10 |
| RockyRoad | ah ... thanks again jelmer | 13:10 |
| RockyRoad | jelmer: I'm not sure I "resolved" the conflicts the right way: current status shows all files renamed to *.moved, and the working files added | 13:19 |
| RockyRoad | would the link between branches be lost if I cancelled this rename operation ? | 13:22 |
| * Peng_ leaves. | 13:23 | |
| kirkland | hiya, vcs-import issues .... | 13:31 |
| kirkland | https://code.edge.launchpad.net/~vcs-imports/qemu/qemu-kvm | 13:31 |
| kirkland | wgrant pointed me here :-) | 13:31 |
| LarstiQ | right | 13:31 |
| * LarstiQ frowns at wgrant ;) | 13:31 | |
| kirkland | heh | 13:32 |
| wgrant | LarstiQ: It's clearly a bzr-git issue, though. | 13:32 |
| LarstiQ | kirkland: in this specific case, you don't want to ask about your vcs import | 13:32 |
| LarstiQ | wgrant: yes, gimme a sec :P | 13:32 |
| kirkland | LarstiQ: okay, i won't ask about my vcs import | 13:32 |
| LarstiQ | kirkland: you want to ask jelmer about the bzr-git issue displayed | 13:32 |
| cody-somerville | jelmer, Were you able to fix my bzr-git issue yet? ;] | 13:32 |
| LarstiQ | kirkland: the bzr-git author can't jiggle the vcs-import, but he _can_ fix the upstream bzr-git problem | 13:32 |
| kirkland | LarstiQ: cool, thanks. | 13:33 |
| kirkland | jelmer: issues bzr-git importing qemu-kvm :-) | 13:33 |
| jelmer | kirkland: I think that one is actually fixed but waiting for launchpad to upgrade to a newer bzr-git | 13:33 |
| jelmer | cody-somerville: not yet, sorry | 13:33 |
| kirkland | jelmer: cool, thanks | 13:33 |
| kirkland | LarstiQ: back at you :-) | 13:33 |
| LarstiQ | kirkland: my work is done I think, back to wgrant ;) | 13:34 |
| kirkland | LarstiQ: heh | 13:34 |
| cody-somerville | jelmer, Is there any way I can bribe you to fix it sooner? ;] | 13:34 |
| LarstiQ | kirkland: or well, someone from lp vcs-imports, mwhudson maybe | 13:34 |
| * wgrant is tempted to bounce it to CHR :P | 13:34 | |
| kirkland | LarstiQ: thanks; and that goes in #launchpad or #bzr ? | 13:36 |
| wgrant | #launchpad | 13:36 |
| wgrant | vcs-imports is a Launchpad thing. It just happens to use bzr. | 13:36 |
| === Kissaki^0ff is now known as Kissaki | ||
| jelmer | cody-somerville: can you donate me some spare time ? ;-) | 13:42 |
| cody-somerville | jelmer, That I don't have any of | 13:42 |
| vila | RockyRoad: the link would not be lost, but the branches don't know that they are talking of the same files. When your resolve a name conflict (the ones that produce the .moved files), you're telling bzr which file you keep. | 13:56 |
| === mrevell-lunch is now known as mrevell | ||
| vila | s/talking of/talking about/ | 13:58 |
| RockyRoad | vila: I could not revert renaming ... not sure now when | 13:58 |
| mario_ | hi folks, how are you doing? | 13:59 |
| vila | RockyRoad: to track renames, bzr gives a file-id to each file when it first encounters it | 13:59 |
| RockyRoad | I checked that there was no diff between .moved and main | 13:59 |
| vila | RockyRoad: since you created your two branches indenpendently, the files are different as far as bzr is concerned | 13:59 |
| RockyRoad | so what should I have done ? | 14:00 |
| vila | if you intend to continue using the two branches, you'd better recreate the smaller one from the bigger one | 14:00 |
| RockyRoad | why ? | 14:01 |
| === cprov1 is now known as cprov | ||
| RockyRoad | oh sorry | 14:01 |
| RockyRoad | did read correctly | 14:01 |
| RockyRoad | didn't * | 14:02 |
| RockyRoad | :D | 14:02 |
| vila | RockyRoad: because further merges will respect your conflict resolution so the only changes that will be taken into account will be the ones to the file you kept (but some changes may lead to the same kind of conflict) | 14:02 |
| * RockyRoad needs to read that a couple of times ... | 14:04 | |
| vila | RockyRoad: even better, try it with dummy branches | 14:05 |
| RockyRoad | vila: I'm a bit lost. Did you read above what I'm trying to do (11:46 GMT) ? | 14:07 |
| * vila re-reading that and the blog post you refer to | 14:08 | |
| RockyRoad | the blog talks about file-ids, doesn't give a solution | 14:09 |
| vila | RockyRoad: well, in the general case, file-ids (in addition to tracking renames) guard against two people creating the same file for different purposes, clearly a conflict | 14:10 |
| RockyRoad | then how do I tell bzr that 2 files are the same | 14:11 |
| RockyRoad | ? | 14:11 |
| RockyRoad | ( they are indeed ) | 14:11 |
| vila | you can't :-/ | 14:12 |
| RockyRoad | and the merge generated conflicts | 14:12 |
| RockyRoad | So I couldn't have avoided the renames ? | 14:12 |
| RockyRoad | The result is not bad however, according to bzr viz | 14:13 |
| RockyRoad | the old branch revisions show up with a 0. prefix | 14:14 |
| ddaa | actually, there are very good reasons that you cannot track renames, do merging and tell a vcs that two files created independently are the same. | 14:14 |
| RockyRoad | and connected to whole history :) | 14:14 |
| vila | RockyRoad: you could have avoided the renames by using the same file-id at 'bzr add' time by using the --file-ids-from | 14:14 |
| ddaa | occasionally, you brash dvcs developper think they can solve the problem, and they body is usually found deep in a jungle of corner cases, their body devoured by cannibals. | 14:15 |
| ddaa | s/you brash/a young branch/ | 14:15 |
| ddaa | s/young branch/young brash/ | 14:15 |
| ddaa | however, there's one thing that should be possible | 14:16 |
| vila | RockyRoad: I realize that sounds a bit un-natural, but building history backwards is certainly not dvcs strong point (for any value of dvcs except darcs :-) | 14:17 |
| RockyRoad | yep I thought it would be easier when I started ;) | 14:17 |
| ddaa | which is define equivalence classes between files, to avoid repeated merge conflicts, but that would still lose a lot of annotate and log information. | 14:17 |
| ddaa | vila: I'd be curious to learn something about the darcs2 model. I heard that they backtracked on most of the patch algebra magic kool-aid. | 14:18 |
| ddaa | but it's kinda hard to come up with good "explanation for dvcs geeks" type of documentation for anything | 14:19 |
| vila | ddaa: all my darcs knowledge is by darcs users, I've yet to encounter a darcs2 user :-) | 14:19 |
| RockyRoad | vila: I never used bzr add in that case. The merge command caused it, with the renames. | 14:20 |
| vila | RockyRoad: I understand that, but the '--file-ids-from' option exists only for bzr add :-) It would be highly non-trivial to add it to merge :) | 14:20 |
| ddaa | s/highly non-trivial/so complex that nobody could even tell whether it's correct/ | 14:21 |
| RockyRoad | oh so your answer was more general than my case ... | 14:22 |
| vila | RockyRoad: it's the closest I could think about avoiding creating two file-ids for the "same" file | 14:22 |
| RockyRoad | It's very interesting. | 14:23 |
| vila | Adding the option to fast-import may be easier and more useful though | 14:23 |
| RockyRoad | My main point was to link the branches. It succeeded. Avoiding renames was more a theorical question | 14:24 |
| vila | It may still need some help from the user if the file has been renamed since it enters bzr, but that may be manageable for small to medium sized project | 14:24 |
| vila | RockyRoad: Oh yes ! You don't intend to update the old branches anymore ! | 14:25 |
| RockyRoad | no | 14:25 |
| RockyRoad | it's more "memory" | 14:25 |
| RockyRoad | s/more/for/ | 14:25 |
| vila | So have a look at 'bzr annotate' for the conflicted files, you may have lost some per-file history even if you still have a complete tree history | 14:25 |
| vila | lost being too strong here, disconnected is closer | 14:26 |
| * RockyRoad never used annotated yet | 14:27 | |
| vila | RockyRoad: did you merge the "old" into the "new" or the opposite ? | 14:27 |
| RockyRoad | the old into the new | 14:27 |
| vila | RockyRoad: Right, so if you're happy with what 'bzr qlog' or 'bzr viz' show, it's the best you can achieve | 14:28 |
| RockyRoad | but new=B , which has history before the new ... quite complicated ;) | 14:28 |
| vila | Well, it means the "old" history (with the 0. prefix) now appears as merged recently instead of preceding revision 1 | 14:29 |
| RockyRoad | yes | 14:30 |
| vila | And that's exactly what you did (from bzr point of view) even if it's not exactly what happened | 14:30 |
| RockyRoad | the newly created project then only described revisions actually older than the 0. branch | 14:31 |
| RockyRoad | I'll add newer revisions after | 14:32 |
| RockyRoad | bzr rocks :) | 14:38 |
| beuno | It sure does! | 14:38 |
| vila | :-) | 14:38 |
| ddaa | RockyRoad: hint, try typing "bzr rocks" in a terminal. | 14:43 |
| RockyRoad | Now next step should be fun: in project A the main branch had been itself split in two, each one doing some merges from the other ... | 14:43 |
| RockyRoad | :) | 14:44 |
| vila | beuno, get out of RockyRoad computer will you... | 14:44 |
| RockyRoad | I wondered if he was a bot :D | 14:45 |
| vila | jelmer: your 'Fix version in dev7 string' bundle is an empty patch | 14:45 |
| jelmer | vila: yeah, Aaron already mentioned that as well | 14:45 |
| jelmer | vila: I'm going to send an updated bundle soon | 14:45 |
| vila | jelmer: sorry for the noise then | 14:45 |
| vila | RockyRoad: the day bots are as full of life as beuno I buy one just for fun :) | 14:46 |
| vila | a bot, not a beuno | 14:46 |
| RockyRoad | lol | 14:46 |
| * beuno for sale, only $699! | 14:47 | |
| vila | beuno-like-bots, the anti-HG2-Marvin :) | 14:50 |
| gioele | hello | 15:01 |
| ddaa | Anyone can point me to the part of the documentation that explains how to set up rule-based default push locations? | 15:23 |
| ddaa | http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#configuration-settings | 15:28 |
| ddaa | the ref manual is great, but it's hard to browse and not very link-friendly | 15:29 |
| gioele | I want to use bzr to track binary large files with rare changes. Which repository format do you suggest? | 15:42 |
| pygi | gioele: possibly brisbane core, as it'll be the only one supported in 2.0 as stable? | 15:43 |
| gioele | pygi: I don't see brisbane-core as a good choice until 2.0 is released | 15:44 |
| vila | ddaa: you should use locations.conf and the magic bit is push_location:policy = appendpath | 15:55 |
| ddaa | Yep, I figured it all out. Thanks. | 15:55 |
| ddaa | I was mostly complaining at how hard it is to locate this piece of information. | 15:56 |
| ddaa | Although it's a bit of major bzr coolness. | 15:56 |
| vila | gioele: if you prefer to stick with default formats, just use the default format. brisbane-core will help a bit, but large binary files with few changes are still not optimally handled anyway | 15:57 |
| vila | ddaa: patches welcome ! :-) | 15:57 |
| vila | jam: ping | 15:57 |
| jam | hey vila, I'm going to be afk for about an hour | 15:57 |
| jam | anything i can help you with quickly? | 15:57 |
| ddaa | vila: maybe one day the formatting of the documentation will cross my itching threshold and I'll get the source and fix the stylesheet. | 15:57 |
| gioele | vila: I suspect large binary files are not a priority, even for 2.0. Isn't it. It is understandable | 15:58 |
| vila | jam: lol, right, so I'll call you next week | 15:58 |
| jam | :) | 15:58 |
| jam | yeah, we should get another phone call in. Want to say this time Monday? | 15:58 |
| jam | (I could even go ~1 hr earlier if that works better for you) | 15:58 |
| vila | jam: could that be one hour earlier... I hate it when you read what I typing before receiving it :-) | 15:59 |
| vila | jam: I'll call you directly Monday then | 15:59 |
| jam | k | 16:00 |
| === zirpu2 is now known as zirpu | ||
| dash | good morning | 16:32 |
| dash | i'm getting an exciting error from bzr svn-import | 16:33 |
| dash | (which Twisted uses to mirror its svn repo into bzr branches) | 16:33 |
| dash | http://pastebin.com/m7d105357 | 16:33 |
| dash | think updating to the latest version will be enough to remedy this? | 16:33 |
| jelmer | dash: not sure | 16:36 |
| jelmer | dash: could be | 16:36 |
| dash | i suspect the culprit here is that I resurrected a deleted branch | 16:37 |
| dash | at least, that's the only unusual thing I can think of here | 16:37 |
| VSpike | Hi. I having a problem renaming a file that is shown as removed. It complains that the original is not versioned. http://pastebin.com/m1712a43e | 16:38 |
| VSpike | Any ideas? | 16:38 |
| dash | hmm. seems to give the same error on 1.15 and 0.6.1 | 16:40 |
| dash | would it help or hurt to use 'bzr branch' to import that branch into the repo? | 16:43 |
| jelmer | dash: please file a bug | 16:43 |
| dash | alrighty | 16:44 |
| VSpike | Am I missing something really simple here? | 16:51 |
| jelmer | VSpike: I think you need "bzr rename --after" or something like that | 16:52 |
| dash | jelmer: #383980 | 16:54 |
| === Isaiah1 is now known as Isaiah | ||
| VSpike | jelmer: bzr rename is a synonym for "mv" and "move". Also, if the old file is missing and the new file exists, it assumes --after | 17:08 |
| VSpike | jelmer: that said, I've tried mv and rename, both with and without --after | 17:08 |
| VSpike | jelmer: I did a whole set of them and that is the only one that failed | 17:08 |
| dash | hm | 17:11 |
| dash | looks like explicitly grabbing that branch made it work again | 17:11 |
| ddaa | Ooooh | 17:13 |
| ddaa | Now bzr log --line automatically add the [merge] tags | 17:13 |
| ddaa | that I used to put in my commit logs for merge ever since... gnu arch... | 17:13 |
| * ddaa claims fatherhood of this idea | 17:16 | |
| * mneptok files for child support | 17:20 | |
| ddaa | Come on, you could not tell a dvcs from a pot bong at the time! | 17:21 |
| mneptok | is the "dd" in your nick for "Deadbeat Dad?" | 17:22 |
| * ddaa admits he's got only the foggiest idea what "child support" and "deadbeat parent" mean and how that relates to anything. | 17:24 | |
| * ddaa uses google | 17:25 | |
| ddaa | mneptok: you can freely use my legacy in launchpad-bazaar code to support this child. | 17:25 |
| mneptok | ddaa: great. more orphans. ;) | 17:27 |
| * mneptok hugs ddaa | 17:28 | |
| * ddaa hugs mneptok | 17:28 | |
| mneptok | et ... ca va? | 17:28 |
| ddaa | on fait aller | 17:28 |
| ddaa | resigned from the bank | 17:28 |
| ddaa | working at home on some start up business | 17:29 |
| ddaa | hence irc | 17:29 |
| mneptok | excellent. best of luck, and have fun! | 17:29 |
| * mneptok is sitting waiting for a .fi phone call before dealing with a bank | 17:29 | |
| RockyRoad | Hi again :) | 18:22 |
| RockyRoad | I'm trying to compare revisions of different branches, something like (from branchB directory) | 18:22 |
| RockyRoad | bzr diff --old=revno:5:lp:branchA --new=revno:6 | 18:22 |
| RockyRoad | what's wrong ? | 18:23 |
| RockyRoad | without filename, I get no result , and with I get "Path(s) are not versioned" | 18:24 |
| RockyRoad | I probably misunderstood the doc | 18:24 |
| RockyRoad | this revisions identifiers | 18:25 |
| RockyRoad | I tried also to replace lp: with bzr+ssh:/bazaar.launchpad.net , no luck | 18:27 |
| jfroy | hello people | 18:28 |
| jfroy | any recommendations on a tool to browse revisions across many related branches | 18:28 |
| jfroy | well, more specifically, I'm interested in finding the set of revisions in a certain branch that have modified a certain set of files. | 18:28 |
| jfroy | Wondering what tools are available to accomplish that. | 18:29 |
| RockyRoad | I would do it from xmloutput + xpath ... | 18:30 |
| === thekorn_ is now known as thekorn | ||
| RockyRoad | does it help jfroy ? | 18:35 |
| jfroy | I'm not sure :p | 18:37 |
| jfroy | Wish I had something like github's history view right about now >.> | 18:43 |
| === abentley1 is now known as abentley | ||
| james_w | jfroy: qlog from qbzr can do some things like that I believe | 18:46 |
| jfroy | yes, I've been using that | 18:47 |
| jfroy | it's mostly working as expected | 18:47 |
| jfroy | but it's not "great" | 18:47 |
| jfroy | this stuff needs to be brought into Loggerhead... | 18:47 |
| james_w | I agree | 18:47 |
| jfroy | ok, let's try to be more simple | 18:57 |
| jfroy | is there a tool / command to list all revisions in a branch that have touched a specific file | 18:57 |
| jfroy | duh, log | 19:02 |
| jfroy | brain not working right today | 19:02 |
| === vxnick is now known as vxnick_away | ||
| ddaa | oh another thing where bzr is better than hg | 19:17 |
| ddaa | bzr log is useful to see in which files were renamed | 19:17 |
| ddaa | while hg log only present renames as add+remove. | 19:17 |
| awilkins | Does Hg have copy? | 19:36 |
| awilkins | Bazaar doesn't have copy | 19:36 |
| === mneptok is now known as mneptok|take_the | ||
| === mneptok|take_the is now known as mneptok | ||
| ddaa | I do not know that it has copy. So I would guess it does not have it. | 19:37 |
| ddaa | Otherwise I think I'd have heard of it. | 19:37 |
| ddaa | I'm just inclined to think their "rename support" is just a quick patch over an anterior data model that did not support it. | 19:38 |
| ddaa | But I'd love to be proven wrong. | 19:38 |
| LarstiQ | I believe hg has copy | 19:40 |
| LarstiQ | ddaa: hg blame -fun file | 19:40 |
| LarstiQ | not exactly showing renames, but can help answer some of the same sort of questions | 19:40 |
| ddaa | oh right, hg has copy tracking | 19:41 |
| ddaa | I stand corrected. | 19:41 |
| ddaa | now, I wonder how they handle that in merges | 19:42 |
| ddaa | I believe one reason bzr does not have copy is there is no one right way to handle that in merges. | 19:43 |
| ddaa | Actually no, since bzr has a real rename, it can decided just not to propagate changes across copies on merge. | 19:46 |
| ddaa | But since hg does not have a real rename, I wonder what they do. | 19:46 |
| LarstiQ | ddaa: one reason bzr does not have copy tracking is indeed because no consensus has been reached (or implementation) on how to handle copies on merges | 19:48 |
| ddaa | I know it's beating a dead horse, but we could just decide NOT to propagate them. | 19:49 |
| ddaa | it's simple to implement, unsurprising, and does to exclude other added value of copying: better log and annotate. | 19:49 |
| * ddaa reflects that apparently his year at the bank taught him a lot about taking SOME decision on complicated technical problem. | 19:50 | |
| ddaa | s/does to exclude/does not exclude/ | 19:51 |
| LarstiQ | ddaa: I very much agree on the importance of taking decisions | 19:54 |
| * LarstiQ is not an interested party when it comes to copy tracking though | 19:54 | |
| ddaa | it's quite important for bzr-svn | 19:55 |
| * LarstiQ nods | 19:55 | |
| LarstiQ | yeah, that's the main driver I'm aware of | 19:55 |
| ddaa | Oh also, another thing where hg sucks: it has non-standard option parsing: you cannot add options after positional arguments. | 19:57 |
| ddaa | maybe not non-standard, but at least non-gnu. | 19:58 |
| LarstiQ | old-style unix though | 19:58 |
| ddaa | let them use sh, nvi, and rcs then! | 19:58 |
| LarstiQ | where I hate that the most is in scp | 19:58 |
| LarstiQ | scp file host: -l login? nooo | 19:59 |
| ddaa | scp is a bit of a world unto its own when it comes to command-line parsing | 19:59 |
| ddaa | would be nice if could catch up with the last 10 years in internet protocols development and support URIs... | 20:00 |
| Youssef | hi all | 20:24 |
| Youssef | I have a question | 20:26 |
| LarstiQ | Youssef: sure | 20:27 |
| Youssef | its about the documentation | 20:27 |
| Youssef | I have made a user guide of Bazaar for windows | 20:28 |
| Youssef | okay | 20:28 |
| Youssef | and I will publish it over internet | 20:28 |
| Youssef | but | 20:28 |
| Youssef | i took 2 or 3 picture from the official website | 20:28 |
| Youssef | do i have permission? | 20:29 |
| Youssef | to do that? | 20:29 |
| Youssef | LarstiQ ? | 20:31 |
| Youssef | brb | 20:31 |
| beuno | Youssef, sure, that's fine | 20:31 |
| Youssef | really? | 20:31 |
| Youssef | cool | 20:31 |
| Youssef | thanks a lot | 20:31 |
| Youssef | ++ | 20:31 |
| LarstiQ | gah | 20:32 |
| * LarstiQ wanted to ask if he could at least mention it, if not contribute it back | 20:32 | |
| beuno | sorry :) | 20:32 |
| joschan | Hi. Is there s way to make a graphical represntation of my branches? | 20:40 |
| beuno | joschan, using bzr-gtk | 20:40 |
| beuno | you have "bzr viz" | 20:40 |
| joschan | that's new? i have 1.12 | 20:42 |
| LarstiQ | joschan: it's old, but it requires the bzr-gtk plugin be installed | 20:44 |
| LarstiQ | joschan: or the qbzr pluing for qlog if you prefer | 20:44 |
| joschan | oh i am on windows. i need a linux machine with gui i see - thank you | 20:48 |
| LarstiQ | joschan: no, qbzr is bundled with the Windows installer | 20:48 |
| joschan | is there a way to just generate jpg files or something? | 20:48 |
| LarstiQ | joschan: and you can run bzr-gtk on windows too | 20:48 |
| LarstiQ | joschan: try `bzr qlog` | 20:49 |
| joschan | LarstiQ: i get a gui on windows yes! | 20:49 |
| LarstiQ | joschan: good :) | 20:50 |
| pygi | LarstiQ: so-so, not perfectly yet | 20:51 |
| pygi | (bzr-gtk on win) | 20:52 |
| LarstiQ | pygi: it's not trivial, but it can be done | 20:52 |
| pygi | LarstiQ: it will be trivial by the time 2.0 is out | 20:52 |
| pygi | (or at least I hope so) | 20:53 |
| * LarstiQ prefers more effort being put into qbzr/tortoise though | 20:53 | |
| LarstiQ | pygi: how are you going to accomplish that? | 20:53 |
| ddaa | esp. tortoise | 20:53 |
| pygi | LarstiQ: easy, by building a easy win installer for bzr-gtk :) | 20:53 |
| ddaa | some people won't touch a vcs with a ten-feet pole unless it is "like tortoise". | 20:53 |
| * LarstiQ nods at ddaa | 20:54 | |
| pygi | ddaa: my interest in tortoise right now is mostly consisted of removing atl stuff | 20:54 |
| ddaa | It does make me want to slap them with a less than perfectly fresh trout, but I guess it's their prerogative. | 20:54 |
| LarstiQ | pygi: ok, so how am I going to motivate you to do that? :) | 20:54 |
| LarstiQ | pygi: atl? | 20:54 |
| pygi | LarstiQ: yes, right now we need visual studio pro for compiling Tortoise | 20:55 |
| pygi | LarstiQ: gimme a big fat paycheck? :-P | 20:55 |
| LarstiQ | ah | 20:55 |
| LarstiQ | pygi: that, I can't do | 20:55 |
| ddaa | what is "atl"? | 20:55 |
| pygi | dash: a set of C++ classes for COM objects programming | 20:56 |
| pygi | LarstiQ: then implement some feature for me :P | 20:56 |
| ddaa | poor dash, he did not ask anything :) | 20:56 |
| pygi | bleh | 20:56 |
| joschan | Is there a way to generate an image file llike png instead of using a gui? | 20:56 |
| dash | i thought about it though | 20:56 |
| dash | but the i remembered what atl is | 20:56 |
| pygi | ddaa* | 20:56 |
| pygi | :) | 20:56 |
| pygi | LarstiQ: actually, I have it almost ready :P I just need to fix one bug | 20:57 |
| ddaa | joschan: there's a ancestry-graph thingy that uses graphviz | 20:57 |
| ddaa | that will happily produce senselessly detailed and overcomplex ancestry graphs | 20:57 |
| joschan | ddaa: thank you, i will try and find | 20:58 |
| joschan | oh... | 20:58 |
| pygi | LarstiQ: if you want to help with the bug, its most welcome :p | 20:58 |
| LarstiQ | joschan: `bzr graph-ancestry` | 20:58 |
| LarstiQ | joschan: not sure what visualisation you're after though | 20:58 |
| pygi | (its not too-complex, I just need time) | 20:58 |
| LarstiQ | pygi: what bug? | 20:59 |
| joschan | LarstiQ: something that just works and is simple and does not depend on much. i do often switch machines and have limnux and windows | 20:59 |
| pygi | LarstiQ: I need to reconstruct icons path on windows | 20:59 |
| LarstiQ | joschan: that still doesn't say anything about the visualisation | 20:59 |
| LarstiQ | pygi: ah | 21:00 |
| LarstiQ | joschan: what are your visualisation requirements? what specifically are you wanting to visualise? | 21:00 |
| dash | world peace | 21:00 |
| pygi | cannot compute, please try something else! | 21:01 |
| joschan | LarstiQ: i want the branch history | 21:02 |
| LarstiQ | dash: http://www.nytms-se.se/ | 21:03 |
| joschan | anything graphical would be fine | 21:03 |
| joschan | i saw the "network graph" on github | 21:04 |
| LarstiQ | graphing the entire ancestry usually isn't very sensible | 21:04 |
| joschan | it is just to understand my own version history better | 21:04 |
| LarstiQ | joschan: could you point me at a github image you like? | 21:04 |
| joschan | LarstiQ: i have no experience, what is better? | 21:04 |
| ddaa | LarstiQ: Address Not Found | 21:05 |
| LarstiQ | ddaa: gah, sorry. com, not .se http://www.nytms-se.com/ | 21:05 |
| LarstiQ | joschan: when I want to investigate my branching history, I usually use qlog or viz | 21:06 |
| joschan | LarstiQ: a nice one is here: http://github.com/ginatrapani/todo.txt-cli/network | 21:06 |
| LarstiQ | and just plain `bzr log` of course | 21:06 |
| LarstiQ | ah hmm, that looks like it needs flash :/ | 21:06 |
| * LarstiQ reads http://github.com/blog/39-say-hello-to-the-network-graph-visualizer | 21:07 | |
| joschan | LarstiQ: viz would be an option if it simply runs anywhere, also qlog, nut i need something that just works | 21:07 |
| LarstiQ | for what value of 'just work' don't they? | 21:09 |
| * beuno has plans for loggerhead-viz | 21:09 | |
| LarstiQ | joschan: git works slightly differently than bzr, the closest analogue to github's network graph is running qlog/viz on multiple branches | 21:10 |
| LarstiQ | beuno: good | 21:10 |
| ddaa | actually that's something I occasionnaly wanted | 21:11 |
| ddaa | But I'm not sure how much the viz layout algo would have to be modified to deal with multiple branches. | 21:11 |
| joschan | which one woul run on linux and windows with less hassle installing, qlog or viz? | 21:12 |
| joschan | i don't want to run into windows installing problems | 21:12 |
| joschan | ok, i see, qlog already works now on my windows machine | 21:13 |
| LarstiQ | joschan: qlog is easiest | 21:14 |
| LarstiQ | ddaa: from `bzr help qlog`: bzr qlog ~/repo/branch1 ~/repo/branch2 | 21:14 |
| ddaa | oh, actually bzr vis seems to have the same | 21:15 |
| LarstiQ | ddaa: and viz has --all I think? | 21:15 |
| * LarstiQ nods | 21:15 | |
| ddaa | yeah, it has the same, lovely | 21:15 |
| ddaa | it was not there last time I looked | 21:15 |
| ddaa | man, I so much fell behind | 21:15 |
| ddaa | but otoh I could not longer take the bzr ml traffic. | 21:16 |
| joschan | i think bzr qlog is fine. i can takeexpand and take screenshots, it helps a lot :-) did not know it is there | 21:17 |
| joschan | s/takeexpand/expand it/ | 21:17 |
| LarstiQ | ddaa: yeah :/ | 21:17 |
| * LarstiQ keeps getting backlogged | 21:17 | |
| LarstiQ | joschan: ah right, sorry, should have mentioned that | 21:17 |
| joschan | yes but it is also interesting to know about the other stuff, also "bzr graph-ancestry", i would love to try that | 21:18 |
| LarstiQ | beuno: hmm, I'm looking on bitbucket for some visualisation I thought I saw there, can't seem to find it | 21:18 |
| LarstiQ | joschan: you should have that command too on windows | 21:19 |
| LarstiQ | joschan: though you might be missing graphviz itself | 21:19 |
| LarstiQ | ooh | 21:20 |
| * LarstiQ can use his lp openid to sign in on bitbucket | 21:20 | |
| joschan | LarstiQ: i just installed graphviz with the msi installer but bzr does not find it | 21:24 |
| LarstiQ | joschan: you should be able to make it a two-step proces. `bzr graph-ancestry ancestry.dot; dot -Tpng ancestry.dot > graph.png` | 21:27 |
| LarstiQ | joschan: on the bzr-gtk trunk that results in: graph.png: PNG image, 1657 x 12643, 8-bit/color RGBA, non-interlaced | 21:28 |
| LarstiQ | joschan: so consider yourself warned, it can get huge :) | 21:28 |
| ddaa | as in "turn your computer into a pancake huge" | 21:29 |
| joschan | hehe | 21:29 |
| fullermd | Wow, bzr can do that too?? I gotta get my syrup... | 21:29 |
| joschan | where do i get that "dot" command? | 21:30 |
| LarstiQ | joschan: it's part of graphviz | 21:31 |
| LarstiQ | joschan: not sure how you invoke graphviz/dot on windows exactly | 21:31 |
| LarstiQ | joschan: but it can convert what graph-ancestry produces when it's writing to .dot | 21:31 |
| LarstiQ | joschan: I suppose if `dot` from graphviz is in PATH, then `bzr graph-ancestry foo.png` can do the invocation itself | 21:32 |
| joschan | i found it in graphviz's bin dir | 21:33 |
| joschan | and it produced a png | 21:33 |
| joschan | :-] | 21:33 |
| joschan | i will photoshop it and show you in an hour os so - takes ages opening *g | 21:34 |
| joschan | s/os/or/ | 21:34 |
| GPHemsley | Is it possible to import/convert data from SVN into an existing Bazaar repository that already has data in it? | 21:34 |
| LarstiQ | joschan: no kidding :) | 21:34 |
| LarstiQ | joschan: that's the problem with trying to display that amount of information, it swamps you | 21:34 |
| LarstiQ | GPHemsley: repository or branch? | 21:35 |
| LarstiQ | GPHemsley: you can do `bzr branch url/to/branch/in/svn` if you have bzr-svn installed | 21:35 |
| joschan | to be hnest i opend it with ms photo editor but i stopped it after 1 minute | 21:35 |
| GPHemsley | LarstiQ: I want to merge in SVN history to an existing Bzr repo | 21:36 |
| joschan | LarstiQ: i have some facts now: 1) don't open a png in ms photo editor - it could just hang 2) the png is really small | 21:37 |
| LarstiQ | GPHemsley: I can be pedantic and say that is no problem at all, or guess that you mean branch instead of repo, and ask you to elaborate somewhat | 21:38 |
| LarstiQ | joschan: hah | 21:38 |
| GPHemsley | meh | 21:38 |
| GPHemsley | this darn terminology | 21:38 |
| LarstiQ | GPHemsley: it helps if you explain the situation in more depth, then it's clearer what is what | 21:38 |
| LarstiQ | GPHemsley: are the bzr branch and the svn branch logically the same project? | 21:39 |
| LarstiQ | GPHemsley: are you just interested in some random files? | 21:39 |
| GPHemsley | LarstiQ: They don't share files, no | 21:39 |
| LarstiQ | etc | 21:39 |
| LarstiQ | GPHemsley: ok | 21:39 |
| GPHemsley | LarstiQ: I want to start a new project/sub-project with Bzr and then move in other code from SVN at a later date | 21:40 |
| joschan | LarstiQ: this is the png inserted into a google doc in original size: http://docs.google.com/View?id=d6snv7k_115ds3qrzfg | 21:40 |
| LarstiQ | GPHemsley: how are your bzr project and svn code related in that case? | 21:41 |
| LarstiQ | joschan: ooh, that's a cutely small ancestry | 21:41 |
| GPHemsley | LarstiQ: They're two sections of the same project. They don't share code, but they're otherwise related. | 21:41 |
| LarstiQ | GPHemsley: say, doc/ and src/, or a library that you contain in the using project? | 21:42 |
| LarstiQ | evening Kinnison | 21:43 |
| GPHemsley | LarstiQ: doc/ and src/ would be the better example, | 21:43 |
| GPHemsley | I think | 21:43 |
| LarstiQ | GPHemsley: do you already have code in bzr, or are you starting fresh? | 21:43 |
| GPHemsley | right now? I'm starting fresh. But I didn't want to do it now. | 21:44 |
| LarstiQ | GPHemsley: good, that is going to prevent us from taking the painful route then | 21:44 |
| LarstiQ | GPHemsley: use bzr-svn to branch from svn (preferably at a level above what you're considering working on, so project/ instead of project/doc or project/src) | 21:45 |
| LarstiQ | GPHemsley: then you at a later date you can just `bzr pull` or `bzr merge` from svn | 21:45 |
| GPHemsley | LarstiQ: I think we'll have to back up, then, because I had trouble installing bzr-svn the last time I tried. :/ | 21:46 |
| LarstiQ | GPHemsley: aha. Well, I can try to help with that | 21:46 |
| * GPHemsley is on a Mac. | 21:46 | |
| * LarstiQ is on a couch ;) | 21:46 | |
| GPHemsley | :P | 21:46 |
| LarstiQ | but yes, Mac is the most difficult target. Still, it shouldn't be too hard, I hope. | 21:47 |
| GPHemsley | me too | 21:47 |
| * LarstiQ looks at the mac installer page | 21:47 | |
| GPHemsley | as I recall, something wouldn't compile right | 21:47 |
| LarstiQ | GPHemsley: how did you install bzr? | 21:48 |
| GPHemsley | the Mac installer | 21:48 |
| GPHemsley | 10.4 | 21:48 |
| LarstiQ | GPHemsley: it claims to include bzr-svn | 21:49 |
| LarstiQ | GPHemsley: what does `bzr plugins` say you have installed? | 21:49 |
| GPHemsley | a number of things, but not bzr-svn | 21:49 |
| GPHemsley | oh, wait | 21:51 |
| GPHemsley | there's svn | 21:51 |
| GPHemsley | well, that's deceiving | 21:51 |
| GPHemsley | looks like it's there, then | 21:51 |
| LarstiQ | GPHemsley: so what happens if you do `bzr ls svn://svn.gnome.org/svn/gnome-specimen/trunk` ? | 21:52 |
| GPHemsley | ah, yes, this was the problem | 21:53 |
| GPHemsley | the problem was with installing subvertpy | 21:53 |
| LarstiQ | ok | 21:55 |
| LarstiQ | hmm, that's not bundled? | 21:55 |
| LarstiQ | it should be | 21:55 |
| LarstiQ | and is indeed listed | 21:56 |
| LarstiQ | according to http://bazaar-vcs.org/MacOSXBundle | 21:56 |
| GPHemsley | bzr: ERROR: No module named subvertpy | 21:56 |
| GPHemsley | You may need to install this Python library separately. | 21:56 |
| LarstiQ | GPHemsley: if that's a recent bzr .dmg, it's bugged and the maintainer should be larted | 21:57 |
| GPHemsley | heh | 21:57 |
| LarstiQ | GPHemsley: if it's not, could you try the newest one? | 21:57 |
| GPHemsley | the newest one is 1.15rc1 | 21:57 |
| LarstiQ | hmm, not that one then | 21:57 |
| LarstiQ | does sound like the OSX maintainer needs some help | 21:57 |
| LarstiQ | GPHemsley: the 1.14.1 one? | 21:58 |
| GPHemsley | that's what I have | 21:58 |
| LarstiQ | ok, it is bugged :/ | 21:58 |
| GPHemsley | heh, the 1.15rc1 doesn't even exist | 21:58 |
| * LarstiQ wonders if there are instructions for how to build the .dmg | 21:59 | |
| GPHemsley | or, rather, the link is bad | 21:59 |
| LarstiQ | and hence, how to build subvertpy | 21:59 |
| LarstiQ | GPHemsley: could you fix it? | 22:00 |
| GPHemsley | sure | 22:00 |
| pickscrape | Hi, any idea how to view a diff of an item on the shelf? | 22:02 |
| LarstiQ | pickscrape: hmm, not with shelve in bzr core. | 22:04 |
| pickscrape | I did think that bzr diff -c shelf:<number> would be sensible, but it no worky | 22:05 |
| pickscrape | --dry-run also just shows a sttus-like list of affected files, and -v made no difference | 22:06 |
| pickscrape | I suppose the only way really is to just unshelve and inspect in the working tree, but that certainly isn't ideal | 22:07 |
| GPHemsley | LarstiQ: Alright, links are fixed. Any luck with the .dmg? | 22:07 |
| LarstiQ | pickscrape: I agree with you | 22:08 |
| LarstiQ | GPHemsley: couldn't find instructions on it | 22:08 |
| LarstiQ | GPHemsley: you could try to compile subvertpy yourself | 22:09 |
| jfroy | yeah, the Mac packages are bad. | 22:09 |
| jfroy | Even the 1.14 one for 10.5 has a broken subvertpy | 22:09 |
| LarstiQ | GPHemsley: depending on the timeframe/effort you want to spend | 22:09 |
| GPHemsley | LarstiQ: That's where I ran into trouble the last time | 22:09 |
| pickscrape | I suppose I really should file a bug about it, if there isn't one already... I'll have a look. Thanks for answering, LarstiQ | 22:09 |
| jfroy | it's probably easier right now to install from easy_install or source | 22:09 |
| LarstiQ | jfroy: are you aware of how to build the .dmg? | 22:10 |
| jfroy | building a package is not too hard, involves using an extension module for setuptools to make a mpkg | 22:10 |
| LarstiQ | jfroy: seems doable | 22:10 |
| jfroy | build_mpkg IIRC | 22:10 |
| GPHemsley | feel free to walk me through it :) | 22:10 |
| jfroy | Ah, it's bdist_mpkg | 22:12 |
| twilight\ | when doing a bzr upgrade in a shared repository, do I also need to perform the upgrade within each contained branch? | 22:13 |
| jfroy | http://pypi.python.org/pypi/bdist_mpkg/ | 22:13 |
| twilight\ | I wouldn't think so, but after upgrading the repo, bzr info within a contained branch says "Repository branch (format: unnamed)" (notice the "unnamed" format) | 22:14 |
| * LarstiQ is a bit of an OSX outsider nowadays, but would like to see the installer in better shape | 22:14 | |
| LarstiQ | twilight\: yes/no | 22:14 |
| GPHemsley | jfroy: Is there a command I can execute to install it? | 22:14 |
| LarstiQ | twilight\: repository, branch and working tree formats can be independent | 22:14 |
| GPHemsley | Or do I have to download it? | 22:14 |
| pygi | LarstiQ: szi is on it, you need to be patient ;) | 22:14 |
| LarstiQ | pygi: no, I need the build instructions to be clear and availabe so anyone can do it :P | 22:15 |
| * GPHemsley is unfamiliar with the Pythong Egg format. | 22:15 | |
| pygi | LarstiQ: actually, the plan is to automate it afaik | 22:15 |
| GPHemsley | heh... interesting typo | 22:15 |
| twilight\ | LarstiQ: is this documented somewhere? | 22:15 |
| LarstiQ | pygi: fine too, as long as the Mac users do not get blocked on the maintainer having time | 22:16 |
| pygi | LarstiQ: but its the same problem with windows so far xD | 22:16 |
| GPHemsley | yeah, that's been kinda annoying in the past | 22:16 |
| LarstiQ | twilight\: which part precisely? For the three formats, see `bzr info -v` | 22:16 |
| GPHemsley | having the Mac packages being many weeks behind... | 22:16 |
| LarstiQ | pygi: I'm not claiming Windows shouldn't be improved ;P | 22:17 |
| twilight\ | LarstiQ: hm, whether or not one has to upgrade each contained branch or just the shared repo | 22:17 |
| GPHemsley | so... how do I install this bdist_mpkg? | 22:18 |
| * LarstiQ gets reminded of something | 22:18 | |
| LarstiQ | twilight\: are these branches, no working trees? | 22:18 |
| twilight\ | LarstiQ: doing 'bzr info -v' within a contained branch (not-manually-upgraded) actually says "repository: Packs 6 rich-root (uses btree indexes, requires bzr 1.9)" | 22:18 |
| twilight\ | correct | 22:18 |
| LarstiQ | twilight\: in that case, there are some formats where it isn't possible to distinguish which one it is unless you have a workingtree | 22:19 |
| LarstiQ | twilight\: but anyway, they should work, upgraded or not | 22:20 |
| pygi | vila: what's sidney's irc handle? | 22:20 |
| LarstiQ | pygi: sidnei? | 22:20 |
| pygi | LarstiQ: possibly :p | 22:20 |
| LarstiQ | pygi: whois him ;P | 22:21 |
| twilight\ | LarstiQ: yup, i just wanted a format with the btree indexes, but in that case it seems like i'm good, thanks | 22:21 |
| pygi | LarstiQ: I don't know his surname xD | 22:21 |
| jfroy | sorry back | 22:21 |
| LarstiQ | twilight\: yeah, that's a repository format property | 22:22 |
| pygi | LarstiQ: he will have a lot of influence on windows builds ;) | 22:22 |
| jfroy | GPHemsley: sudo easy_install bzr; bzr branch lp:subvertpy; cd subvertpy; sudo python setup.py install; cd ..; bzr branch lp:bzr-svn; cd bzr-svn; sudo python setup.py install | 22:22 |
| jfroy | :p | 22:22 |
| GPHemsley | heh | 22:22 |
| jfroy | oh, right | 22:23 |
| jfroy | . | 22:23 |
| jfroy | so, bdist_mpkg is on pypi | 22:23 |
| jfroy | so just do easy_install bdist_mpkg | 22:23 |
| jfroy | then it will add a command to setup.py to build a package distribution | 22:23 |
| LarstiQ | jfroy, GPHemsley: feel free to bug the mac maintainers, tell them I sent you ;) | 22:23 |
| jfroy | do that for bzr, subvertpy, bzr-svn and any other plugin you want | 22:23 |
| jfroy | then get the Mac OS X dev tools and use Package Maker to make a package that will install all the sub-packages | 22:24 |
| GPHemsley | ah.... too much information at once | 22:24 |
| GPHemsley | easy_install command not found | 22:25 |
| jfroy | that's not good | 22:25 |
| GPHemsley | heh | 22:25 |
| GPHemsley | just another thing on that list :P | 22:25 |
| jfroy | easy_install is bundled with 10.4 and later | 22:25 |
| jfroy | no, it means your OS is busted or ancient | 22:25 |
| GPHemsley | well, it's 10.4 | 22:26 |
| GPHemsley | latest point release | 22:26 |
| GPHemsley | .11, I think? | 22:26 |
| jfroy | then you should have it | 22:26 |
| jfroy | along with Python 2.3 as the default system python | 22:26 |
| jfroy | which is *too old* for bzr, mind you | 22:26 |
| GPHemsley | 2.5 | 22:26 |
| GPHemsley | is what I have, IIRC | 22:26 |
| jfroy | that's a custom install | 22:26 |
| GPHemsley | probably, yeah | 22:26 |
| jfroy | can't use that to make a 10.4 package | 22:26 |
| jfroy | it's the biggest issue with 10.4 | 22:26 |
| GPHemsley | d'oh | 22:27 |
| jfroy | on 10.5 it's relatively easy | 22:27 |
| GPHemsley | but the packages released are for 2.5 and 2.6 | 22:27 |
| jfroy | yes for some distribution of Python that the package maintainer has chosed | 22:27 |
| jfroy | *chosen | 22:27 |
| jfroy | whereas the 10.5 package is designed to use the system interpreter | 22:28 |
| GPHemsley | OK, well, despite easy_install not being found, it did the rest of those commands you had | 22:28 |
| jfroy | I'm not familiar with the 10.4 package too much, it was maintained by someone else | 22:28 |
| jfroy | maybe 10.4 didn't have setuptools.... | 22:28 |
| GPHemsley | except the install ones, I guess... :/ | 22:28 |
| jfroy | don't remember, 10.4 is ancient history for me :| | 22:29 |
| GPHemsley | yeah, I know | 22:29 |
| GPHemsley | I always get gypped with Mac stuff | 22:29 |
| GPHemsley | I bought this computer in August 2007 | 22:29 |
| LarstiQ | 'gypped'? | 22:29 |
| GPHemsley | 10.5 came out in, what, October 2007? | 22:29 |
| GPHemsley | LarstiQ: I always buy stuff right before the new stuff comes out. | 22:30 |
| LarstiQ | ah | 22:30 |
| GPHemsley | I bought an iMac G5 in November 2005 and they announced the switch to Intel the next January | 22:30 |
| LarstiQ | ouch :( | 22:30 |
| GPHemsley | yeah | 22:30 |
| jfroy | usually for OSes they have a grace period for updates | 22:30 |
| jfroy | anyways, wait until 10.6 and grab it :) | 22:30 |
| * LarstiQ needs to fix his g4 powerbook | 22:30 | |
| GPHemsley | that's the plan :) | 22:30 |
| GPHemsley | I'm hoping to get a new iMac after 10.6 comes out | 22:31 |
| pygi | GPHemsley: I heard they'll announce new architecture after you buy it | 22:31 |
| GPHemsley | pygi: Yeah, that's the rumor. | 22:31 |
| LarstiQ | pygi: tsk :p | 22:32 |
| GPHemsley | they have replaced a lot of this MBP for free, though, so I can't complain too much | 22:32 |
| joschan | I have a winows machine and I need python2.4 there for a legacy application. When I install bzr from the windows installer - will it disable or override the python 2.4 with 2.5 ? | 22:32 |
| LarstiQ | joschan: won't touch it | 22:32 |
| GPHemsley | my logic board died and they replaced it... then it died again the next day, and they replaced it... and then they replaced the battery recently | 22:32 |
| LarstiQ | joschan: the all-in-one installer has python and bzr combined in one executable, doesn't touch system python | 22:33 |
| awilkins | joschan: If you use the exe-flavoured installer, neither | 22:33 |
| LarstiQ | joschan: the python-based-installer will work with the python version of your choosing | 22:33 |
| jfroy | indeed | 22:33 |
| joschan | LarstiQ: i was planning to use the exe stand alone installer | 22:33 |
| joschan | i did not explain well | 22:33 |
| jfroy | the Python windows installer that most packages use lets you choose which python you want to install into | 22:34 |
| jfroy | based on registered python interpreters it finds int he registry | 22:34 |
| LarstiQ | joschan: no touching of your system python then | 22:34 |
| jfroy | IIRC | 22:34 |
| joschan | how does it do ithat? with a virtual environment? | 22:34 |
| GPHemsley | Ah, yes... this was the error I kept getting when I tried to install subvertpy the last time: | 22:34 |
| GPHemsley | Exception: Subversion development files not found. Please set SVN_PREFIX or (SVN_LIBRARY_PATH and SVN_HEADER_PATH) environment variable. | 22:34 |
| awilkins | joschan: The libraries are compiled into the exe as a resource | 22:34 |
| joschan | or py 2 exe? | 22:34 |
| joschan | ah i see - thank you! | 22:34 |
| awilkins | GPHemsley: Windows or Linux? | 22:34 |
| GPHemsley | awilkins: Mac | 22:35 |
| LarstiQ | GPHemsley: you'll need an equivalent of a `libsvn-dev` package | 22:35 |
| GPHemsley | I have it... but it doesn't see my settings for those env variables | 22:35 |
| GPHemsley | no matter how I set them, it just ignores them | 22:35 |
| LarstiQ | GPHemsley: how did you set them? | 22:35 |
| GPHemsley | export, I believe | 22:36 |
| jfroy | GPHemsley: Mac OS X comes with *no* header files. | 22:36 |
| jfroy | You need to install the dev tools to get them. | 22:36 |
| jfroy | if you're trying to use the system subversion librsries | 22:36 |
| jfroy | *libraries | 22:36 |
| jfroy | And, IIRC, 10.4 may not even have svn built-in :p | 22:36 |
| jfroy | in which case, you need to get it yourself someway and set SVN_PREFIX to the install prefix of the subversion you picked | 22:37 |
| jfroy | e.g. if it's a binary package, likely /usr/local, or if from MacPorts, then /opt/bin | 22:37 |
| jfroy | */opt/local | 22:37 |
| GPHemsley | I already have svn installed | 22:37 |
| GPHemsley | I've been using it | 22:37 |
| GPHemsley | and the dev files are somewhere, too | 22:37 |
| GPHemsley | but when I try to set the variables, it ignores them | 22:37 |
| GPHemsley | and says they're not set | 22:38 |
| GPHemsley | (as above) | 22:38 |
| jfroy | they're env variables, right | 22:38 |
| jfroy | so export SVN_PREFIX=/usr/local (or whatever) | 22:38 |
| jfroy | then python setup.py | 22:38 |
| jfroy | bui;d | 22:38 |
| jfroy | *build | 22:38 |
| jfroy | etc | 22:38 |
| joschan | i don't like magic! at least not on computers. on my girlfriend - yes! | 22:40 |
| joschan | i said bzr init on directory that contains svn | 22:40 |
| joschan | what happened? | 22:40 |
| GPHemsley | jfroy: Meh... it's working now... | 22:40 |
| joschan | it was even trying to connect to the svn server | 22:41 |
| GPHemsley | oh, spoke too soon | 22:41 |
| GPHemsley | collect2: ld returned 1 exit status | 22:41 |
| GPHemsley | lipo: can't open input file: /var/tmp//ccoyGWiH.out (No such file or directory) | 22:41 |
| GPHemsley | error: command 'gcc' failed with exit status 1 | 22:41 |
| LarstiQ | joschan: I'd say it would refuse because it is already a branch | 22:41 |
| GPHemsley | jfroy: I'm pretty sure I used MacPorts to install the dev files | 22:43 |
| joschan | there is a svnb plugin - can i disable this? | 22:43 |
| joschan | s/svnb/svn/ | 22:43 |
| jfroy | GPHemsley: macports always installs the headers | 22:44 |
| jfroy | since it builds from source and all | 22:44 |
| jfroy | the error sounds weird ... | 22:44 |
| GPHemsley | well, I set the variable using /opt/local and that's the error I get | 22:44 |
| joschan | "bzr --no-plugins init" worked fine | 22:46 |
| joschan | is there a --no-magic switch also ;-) | 22:46 |
| LarstiQ | joschan: ehm, are you sure that is what you want to do? | 22:49 |
| LarstiQ | joschan: coversioning a project can be valid, but it has very limited uses | 22:50 |
| GPHemsley | jfroy: Is there a way to uninstall all the SVN stuff and start over, maybe? | 22:50 |
| jfroy | GPHemsley: mac ports can uninstall with uninstall | 22:51 |
| * LarstiQ is about to call it a night | 22:51 | |
| jfroy | you may need to update your dev tools as well | 22:52 |
| jfroy | hard to say | 22:52 |
| LarstiQ | joschan: with bzr-svn you can use bzr as an svn frontend, either `bzr log` etc in an svn checkout, or `bzr branch url/to/svn/branch` and it gives you a bzr branch converted from svn | 22:53 |
| LarstiQ | joschan: with wich you can push back changes et all | 22:53 |
| GPHemsley | jfroy: Oh, here's an interesting piece of information | 22:54 |
| GPHemsley | MacPorts says I have subversion 1.6.2 installed, but svn is reporting it's 1.5.5 | 22:54 |
| * LarstiQ prods joschan | 22:56 | |
| GPHemsley | jfroy: Any idea how to rectify that? | 22:57 |
| LarstiQ | meh, need to sleep | 22:58 |
| GPHemsley | LarstiQ: g'night | 22:59 |
| GPHemsley | and thanks :0 | 22:59 |
| GPHemsley | :) | 22:59 |
| LarstiQ | joschan: tell me what you were trying to do and how that went, I'll read it when I wake up | 22:59 |
| LarstiQ | GPHemsley: np, good luck! | 22:59 |
| jfroy | GPHemsley: seems like you have 2 subversions installed | 22:59 |
| jfroy | maybe one in /usr/local and one in macports | 22:59 |
| GPHemsley | jfroy: Indeed it does | 22:59 |
| jfroy | could make a build system very confused... | 22:59 |
| GPHemsley | nope, no /usr/local/bin/svn | 23:00 |
| GPHemsley | jfroy: Heh. I have a brain and _I'm_ confused :P | 23:01 |
| * GPHemsley sends find off to... well... find | 23:01 | |
| jfroy | which svn | 23:01 |
| jfroy | (that is, run that command) | 23:01 |
| GPHemsley | /opt/local/bin/svn | 23:01 |
| jfroy | well there you go :p | 23:01 |
| GPHemsley | where is MacPorts keeping its version, then? | 23:02 |
| jfroy | if you don't care too much about, and have some free time, you could nuke (or move aside) /opt/local and install a fresh macports | 23:02 |
| jfroy | in there | 23:02 |
| jfroy | dunno what command you did to uninstall it | 23:02 |
| jfroy | might have failed | 23:02 |
| jfroy | or it might have been an inactive version | 23:02 |
| jfroy | (since macports supports having multiple versions of the same port, but with only one active at a time) | 23:03 |
| GPHemsley | wait... uninstall what? | 23:03 |
| GPHemsley | oh | 23:03 |
| jfroy | didn't you say you had uninstalled svn | 23:03 |
| GPHemsley | I don't think so | 23:05 |
| GPHemsley | what is /sw? | 23:05 |
| GPHemsley | because I have /sw/bin/svn which is at 1.2.3 | 23:05 |
| GPHemsley | ugh, I gotta run | 23:06 |
| GPHemsley | jfroy: Will you be here later? | 23:06 |
| joschan | LarstiQ: I wanted to make a new repo aout of a direcotry structure and ignore all the .svn files in it. I could do it using the --no-plugins switch on bzr init and bzr add | 23:06 |
| joschan | so i'm fine | 23:07 |
| joschan | i don't want to mix, i want to abandon subversion | 23:07 |
| jfroy | GPHemsley: sure | 23:11 |
| jfroy | *Fink | 23:11 |
| jfroy | ** /sw is Fink | 23:11 |
| jfroy | joschan: I'd just use bzr-svn to branch the subversion branch. | 23:11 |
| jfroy | you get to keep all the history | 23:11 |
| jfroy | and you have a native bazaar branch moving forward | 23:12 |
| === vxnick_away is now known as vxnick | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!