[00:07] 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] garyvdm: ^ [00:08] Yes [00:08] Give me a sec [00:08] no problem [00:19] awilkins: pong [00:26] tsmithe: http://pastebin.com/m4e620ab5 [00:38] 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. [01:27] Hmm, Loggerhead is using more RAM than usual. [01:36] What does '.. will create a repository within the new branch' mean? Aren't branches supposed to be stored IN repositories? [01:37] Peng_: well i don't think _i've_ committed any code for weeks :) [01:38] GungaJin: I think it means it will put the repository in the .bzr directory that is inside the branch's working directory [01:39] man... it's so confusing that each vcs uses slightly different meanings for the same term... [01:39] I'm not saying that that's the right way for it to say that ... [01:39] just that that's probably what was meant [01:40] GungaJin: if they didn't, they'd be the same vcs probably :) [01:40] well, it also says that 'bzr init' makes a directory a versioned branch... [01:40] dash - not necessarily :) [01:40] could make up new terms [01:41] or take them all from monty python and red dwarf [01:41] :) [01:42] are you storing your gumby in a shared grail? [01:52] You know what's smart? Walking thousands of directories, 3 times. :X [01:53] mwhudson: Yeah, you're probably right. :P Let's blame jelmer, since he's not here! :) [01:54] hello all [01:55] poolie: hello! [01:57] zzzz - time for bed [02:41] jml: re review mail, why not open a bug and post the link to the list [02:41] then maybe once you know, summarize what can be done [02:41] as a workaround, if anything [02:56] jml: Is 'launchpad' or 'launchpad-code' the right place to submit 'code review' bugs? [02:56] lp-code [02:56] morning poolie, jam, all [02:56] hi igc [02:56] morning lifeless, spiv [02:56] lifeless: k, launchpad has the tag 'code-review', but I can migrate my bugs as appropriate [02:57] morning igc [02:57] hi jam - really well done of the bencode stuff [02:57] igc: thanks. Now if I can just get the patch to land :) [02:58] Just silly things like having an old GPL header [02:58] or Revision.parent_ids wanting to be a 'list' rather than a 'tuple' [02:59] jam: :-) [03:00] jam: launchpad-code also has the tag code-review [03:01] 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] hello igc! [03:01] hello lifeless [03:02] igc: Morning, I just reviewed your dirstate patch as it happens :) [03:02] hi spiv, just readng over your comments now [03:03] so spiv, a few things ... [03:04] I did really mean "is not False" - the attribute is tristate ... [03:04] where None means not yet set and False means "don't allow setting to True" [03:05] How can I list all revisions on a branch? [03:05] igc: hmm [03:05] spiv: and some low level dirstate tests do fail from memory if the limit is non-zero [03:05] igc: I get that it's a tristate, but in that case wouldn't "is None" fit better? [03:06] I think they make changes and explicitly go and read the file content, or something like that [03:06] igc: because setting to True when already True is pointless [03:06] spiv: thanks for all your reviews [03:06] spiv: is None would be better [03:07] 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:08] spiv: I did benchmark keeping the lines around at the beginning, at least in Python code (my pyrex sucks) [03:08] dirstate code is fixable now [03:08] as we have a C version and a python version [03:09] 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] 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] jam: does your custom decoder try using a list rather than a dict? [03:09] and the pyrex version can be plan C [03:09] if you did, it'd be getting fairly close to the minimal bytes, i think [03:09] poolie: The format change I made uses a list [03:10] the custom decoder doesn't use either [03:10] it just sets attributes on self [03:10] and then passes those to a Revision object [03:10] 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:11] 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] i meant a bencode list, like l12:mbp@sourcefrog23:mbp@123g131983712983719837e [03:11] 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] 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] spiv: yes, good pointy [03:12] s/pointy/point/ [03:12] poolie: Right, so the new disk format is a list of 2-entry lists [03:12] rather than a dict [03:12] 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] jam: Of [['revid', 'foo@bar-123'], ['author', 'Joe Example <...>'], ...] ? [03:13] jfroy: bzr remove-tree; bzr co -r X ? [03:13] spiv: basically [03:13] jam: IIRC poolie's suggestion was to do away with the key-name elem entirely for the fields that are always present. [03:13] jam: what, you have top delete the tree? [03:13] there's no equivalent to svn up -r foo [03:13] *have to [03:13] jam: so ['foo@bzr-123', 'Joe Example <...>', ...] for that example [03:14] jfroy: https://code.edge.launchpad.net/~mhammond/bzr/update-r/+merge/6980 [03:14] 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] spiv, poolie: So I think we can consider it. [03:14] I kind of like self [03:14] self-describing disk formats [03:14] when possible [03:15] also, it gives me *some* flexibility to change the order if we find something better [03:15] without completely nuking the reader [03:15] though... if we consider the exact bytes to be sanctified, then we'd have to be careful [03:19] jam - your read vs readlines tests [03:19] jam: are they done on many small files, or one huge one? [03:19] lifeless: that test is on one huge one [03:19] the memory consumption is about how many X we are of the largest file [03:19] bahamut$ bzr co -r 769 --lightweight carrier/ carrier-769 [03:19] bahamut$ bzr revno carrier-769/ [03:19] 794 <-- :( [03:19] jam: I think that test is not representative then. Because we can't really scale up that way anyhow. [03:19] we are pretty good about not holding the content of all files the whole time during commit [03:20] I'm about to mail a large file support proposal to the list [03:20] would appreciate your critique of it [03:20] lifeless: well, *today* we have about 5x memory overhead for committing the content of a no-eol file [03:20] so a 100MB file => 500MB during commit [03:20] jam: yes [03:20] and your work is key to making that tolerable [03:20] jam: fixing that issue would be awesome [03:20] I think Loggerhead is leaking bzr-svn-related things. [03:21] I have a few branches that take GBs of real RAM to check out. [03:21] jfroy: I have 2 patches up, which bring it down to 2x for --dev6 formats [03:21] jfroy: checkout != commit [03:21] oh? revno gives the tip revno all the time? [03:21] jfroy: 'bzr revno' is the branch revno, IIRC [03:21] not the WT revno [03:22] that's correct :| [03:22] "This is equal to the number of revisions on this branch" [03:22] soooo [03:22] bzr st says 'working tree is out of date, run 'bzr update'' [03:22] bzr info says nothing [03:23] ahhh [03:23] Surely there's a better way to get a Revision from a revid than doing RevisionSpec.from_string('revid:' + revid), right? [03:23] version-info [03:23] completely unintuitive name [03:23] that command fails [03:23] I mean, it's name is a fail [03:24] fullermd: repo.get_revision(revid) [03:24] I can get the repo from a Branch object, right? [03:25] jfroy: How funny that you're grumpy about revno right at this moment... [03:25] branch_obj.repository, yeah :) [03:30] Oh, heck, it wants a RevisionSpec... [03:30] * fullermd gets grumpy. [03:32] Oh well. Silliness it is then. [03:38] Loading an 8 MB Dozer page is definitelt a good idea. [03:38] Such a good idea that I can't spell it! [03:39] fullermd: why not repository.get_revision(revid) [03:40] Because I need a RevisionSpec, not Revision. [03:40] * thumper sees spiv's response [03:40] fullermd: for what? [03:40] Bah, send -o doesn't expand ~. Hrmph. [03:41] fullermd: "bzr send -o ~foo" would be expanded by the shell, wouldn't it ? [03:41] Probably, but -o~foo isn't. [03:41] I suppose -o~foo might not [03:44] thumper: for https://lists.ubuntu.com/archives/bazaar/2009q2/059119.html [03:46] jfroy: See ^^ [03:47] 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] fullermd: eh [03:47] good enough [03:47] fullermd: you could add a "--both" flag [03:47] which would be suitable for an alias [03:48] like "revnoa" or whatever [03:48] (a -> all) [03:48] spiv: Not sure. revision-info blows up in such cases... [03:48] hello. If I've checked out a branch anonymously, what's the command to authenticate so I can check in? [03:48] jfroy: Well, _you_ could. I just blew my bzr time for the rest of the month on that :p [03:49] fullermd: I'm not surprised... [03:51] Presumably version-info should grow something similar too... [03:51] Actually, version-info probably should DEFAULT to the tree rev, considering its aim. [03:53] fullermd: makes sense to me, but I probably lean towards making revno and revision-info default to the tree rev too... [03:53] I wouldn't argue against that. [03:55] Having the option at least cuts down on my grumpiness a bit anyway. [04:04] * igc lunch [04:04] * spiv -> food, etc [04:04] * spiv hopes this vicious sore throat goes away soon [04:08] oh found it...bzr bind bzr+ssh://... [04:38] mwhudson: ping [04:39] Actually, I don't really need to ping you. [04:39] poolie: you available for a bzr related call? [04:46] Peng_: :) [04:48] mwhudson: Running Dozer is fun! Especially the 20 MB page listing all of the lists! :D [04:49] Loggerhead seems to be leaking some bzr-svn-related stuff. [04:49] From when it scans the directories for branches. [04:52] that sounds vaguely familiar [04:52] Yeah, it does. [04:52] also, i'm tempted to say, NFM [04:53] NMF [04:53] NMF? [04:53] Oh. [04:53] :D [04:53] If one of you enjoys looking at Dozer output for some strange reason, http://bzr.mattnordhoff.com/loggerhead/_dozer/index :D [05:00] A few hundred subversion-related things shouldn't account for much RAM, should it? [05:10] depends what the things are, but no, not really [05:10] Peng_: have you seen jam's py_mem_profile thingy? [05:12] mwhudson: SubversionAuthenticationConfig and SubversionException, FWIW. [05:13] Peng_: those sound small indeed [05:13] mwhudson: I might've read the email, but normally I'm not interested in memory profiling, so I don't remember it. [05:16] Eh, I think the garbage collector keeps doing its job, making it difficult to analyze this. :P [05:17] Anyway! [05:25] spiv: thanks! [05:25] jml: np [05:34] 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] :D [05:37] spiv, i think i asked spm to make access to all branches the same [05:37] at any rate i don't see much value in having different privilege levels [05:44] 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:46] spm: I think it's probably ok to let any committers commit to all branches, but poolie gets the final say. [05:47] spiv: given the trivial diff on those two groups? I'd agree; but as you say :-) [05:47] 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:48] 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:53] jml: (it looks like PQM likes me) [06:01] there are only two groups because when I asked martin 'who do you want to be able to commit to he named a subset [06:01] its trivial to make it just one group [06:04] spiv: :) [06:12] So...the bencode repo format had worse performance than RIO, right? Why was it chosen? [06:12] igc: your dirstate patch [06:13] hi lifeless [06:13] igc: does it actually make saving faster, or does it just save under less circumstances, or both ? [06:13] both [06:13] cool [06:13] did my suggestion make sense? [06:13] yes, I'd liked it and it would be enough for status [06:13] i.e. for faster status [06:14] now [06:14] I have a planned change to dirstate [06:14] for windows [06:14] that will interact, do you have a minute to chat regarding this [06:14] sure [06:15] 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] instead have a current pointer [06:15] and a directory of dirstates [06:16] ok [06:16] so we'll write to a new file when we do an update [06:16] 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] don't we write the lot out again anyhow now? [06:17] yes [06:17] a related but more complex change we could make [06:17] is to go to some sort of journalling system [06:17] I don't think we have the time to do that for 2.0 [06:18] but we do, if we focus, to do the simpler change of having a current pointer and many full dirstates [06:19] it may be that this doesn't really interact with your code at all; in which case cool [06:19] but I thought it was worth running it up the flagpole [06:20] lifeless: I think my change is independent and won't clash in any way [06:21] cool [06:29] * spiv -> giving up for the day. Have a good weekend everyone. I should be over ubuflu by next week :) [06:39] bah! [06:39] cherrypicking is maddening [06:39] is there a revspec to specify "revision xyz up to tip of target branch"? [06:39] -r xyz.. does... bad things [06:40] jfroy: that should work fine; can you expand on bad? [06:41] it goes crazy and conflicts to all hell [06:41] I just want to merge the last 2 revision of A into B (A was branched from B) [06:42] well, its possible that the conflicts are genuine [06:42] do you get them if you apply the revisions as plain patches, or something similar? [06:43] No, there's no way those 2 revisions would conflict. [06:43] And not in the manner it's doing. [06:43] I'm getting content conflicts, file deletes and renames. [06:43] Those 2 revisions are simple edits to a few files. [06:43] sounds like the files were added independently to A and B [06:44] so bzr thinks they are different files that happen to be at the same path [06:44] B was branched from A. [06:44] and has 5 revisions more than A. [06:44] I want to bring the last 2 into A. [06:44] (skipping over the first 3) [06:45] I get that from your prior explanation. However, if you are getting content conflicts it [insert my 'sounds like' above] [06:46] spiv: you should be able to use pqm with lp branches now [06:46] 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] jfroy: you can use 'bzr inventory --show-ids' to debug this [06:46] I'm pretty sure I'm just being stupid [06:46] with the merge command [06:46] and not understanding revspecs :/ [06:47] jfroy: no, I think its something else. Humour me. [06:51] yeah, doing two merge with -c x and -c y worked fine [06:52] (where x < y and {x, y} are the last 2 revisions of the merged branch) [06:52] jfroy: ok, please file a bug [06:52] so, should merge -r x.. do the same merge> [06:52] *? [06:53] roughly [06:53] uhm, it won't include x [06:53] merge -r {x-1}.. [06:54] the range x-1..x == -c x [06:54] yeah, that has a completely different outcome [06:55] whoa [06:55] revision_id = _mod_revision.ensure_null(revision_id) [06:55] ... [06:55] thank you IRC [06:55] bzrlib/repository.py:2308: DeprecationWarning: NULL_REVISION should be used for the null revision instead of None, as of bzr 0.91. [06:55] revision_id = _mod_revision.ensure_null(revision_id) [06:55] the merge basically deletes most of the files in the branch [06:57] however, -r (x-1)..y works fine [06:58] jfroy: definitely file a bug [06:59] will do [07:19] poolie: so 2.0 [07:19] poolie: I agree we need eye on the prize; heck I've been chanting that mantra [07:19] hi all [07:19] 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:20] hello vila! [07:21] lifeless: let's not overcatastrophize the format thing [07:21] hi vila [07:21] 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] 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:22] ok [07:22] noted [07:22] 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] igc: I have some troubles with usertest: 1) selftest is not passing, 2) I get http://paste.ubuntu.com/188798/ [07:23] Obviously, the best way to develop software in general is to use bzr 8-} [07:23] actually, ignore my concerns here. Mark asked for one format in 3.0 [07:24] poolie: and sure, we need to batch things up into larger amounts, get more network independence etc. [07:25] ok, I'm going to halt() now [07:25] i guess briefly i see it as being a lot like an individual release [07:25] still somewhat sinusy but nearly well [07:25] i'd desperately like to fix all the things you name [07:26] but should we slip 1.16 til they're done? probably not, there's good stuff to get out [07:26] poolie: marks mail, april 16th or so 'scoping the ui...' talks about 3.x [07:26] poolie: I had confabulated that to be 2.x in my head [07:26] in 2.x we should do better than we have with plethora-of-formats [07:26] i said the same thing to him, that though i'd love to do them we need to get 2.0 out [07:26] in 3x we're being asked to have one format for the life of the 3.x series [07:27] Just killing off poor roots takes care of probably 75% of that right there... [07:27] the main point is: there should be a clear moment at which we have a new format and migrate people on to it [07:28] 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] i guess the secondary point is: somewhat larger steps, rather than dribs and drabs [07:28] but that can be guided by experience [07:29] 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:30] 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:31] i.e. we don't want to get into rich-root/non-rich-root divergence ever again [07:31] for example [07:31] poolie: so what I'm saying is broadly 'yes', but that 3.x should be more guided by 'we think we have a of breathing room', and that during 2.x we can issue new formats still [07:31] poolie: [if we feel the tradeoffs are worth making] [07:31] lifeless: +1 [07:32] forbiding experiments is definitely counter-productive (as long as they don't make our users cry) [07:33] vila: I don't think anyone is suggesting forbidding experiments [07:33] a single dev format may restrict them a lot [07:34] 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] vila: this is a constraint for 3.x; so we should get comfortable with it during 2.x [07:35] 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] vila: My feeling is that its tied to the size and scope of the change. [07:35] tweaking an API - short lived branch. === thekorn_ is now known as thekorn [07:37] changing how big files are stored - plugin or long lived loom with the bits that we're sure of merged [07:38] 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:39] 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] s/to slow/too slow/ of course [07:41] lifeless: Did you read my post to the list about pbranches style branch management? Do you think it's feasible? [07:41] 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:42] vila: separately, there is 'what is involved in doing status across subtrees'. [07:43] I was thinking about scanning the whole tree to update the dirstate with a tree that will trash the cache [07:43] vila: bzr status main/coreutils would only scan main/coreutils in the cache [07:43] and probably not pass the threshold to trigger a save [07:43] vila: and with subtrees coreutils would be a separate tree anyhow [07:44] vila: so there are two separate places we'd be listing all the subtrees: [07:44] a) dirstate [07:44] b) repository [07:44] they have different IO/compression needs. But nevertheless, what do you think we'd need to index? [07:45] awilkins: I saw it, haven't absorbed it. I think loom is not finished. [07:45] awilkins: and that many issues related to it are due to it not being finished, not due to the design. [07:45] awilkins: and further to that, that the design likely needs improving. [07:46] 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] awilkins: I'm not at all convinced that heuristic full-topological support is good or needed. I think its hugely complex. [07:46] vila: abentley describes this as 'recursing upwards' in the nested tree docs. [07:47] vila: deciding whether in coreutils needs to go upwards *could* be policy. Or it could just never do it. [07:47] recursing upwards sounds evil to me, but I see where it can help here... [07:47] vila: so to commit a snapshot of all of ubuntu you'd explicitly cd to the root and commit [07:47] lifeless: got it [07:59] vila: [oh, and commit --norecurse or whatever would then just grab the last revid from subtrees rather than tryin to commit in them] [08:00] * lifeless halts() for real [08:01] lifeless: that's evil too :-) [08:03] 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:04] That's not perfect, but that will curely covers many needs... [08:33] i really want to talk about the format thing but my batteries are going flat [08:38] poolie: plug yourself ! Enjoy your week-end :) [08:38] btw, [08:38] some people were asking a while ago about how to tell Launchpad to mirror a branch right away [08:38] http://paste.ubuntu.com/188831/ sketches out how to do that. [08:39] If you stay half-asleep all the time, is that like float-charging your batteries? [08:39] it relies on a branch of launchpadlib that I've written. [08:40] fullermd: staying half-awake all the time is very bad for battery life, go get some sleep :-) [08:41] I can't! All the Canonical people are still oversleeping from ubuflu, so I'm stuck on short-time to keep the balance :( [08:42] fullermd: it's ok, I catched up from ubuflu, I'll take care of the balance :) [08:42] ubuflu? Sounds like a disease that afflicts the dog that appeared at the end of the A-Team [08:42] "Sit Ubu, sit!" [08:42] I pity the flu. [08:44] night all [09:25] night all [09:25] igc: Good night. [10:20] * fullermd thinks that's quite enough hackage for one night... [10:27] Hm. I have selftest failures... [10:28] test_two_files_different_versions_no_inconsistencies_bug_165071 fails for me on RepositoryFormat's 5, 6, and 7. [10:59] Hi, can I checkout all branches in a repo easily? [10:59] not really [11:01] wam: You mean all branches in a code.launchpad.net team's page? [11:01] 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] jpds: don't know - I just have a repo with some branches and would like to checkout them all [11:02] You should init-repo [11:02] ok [11:02] Otherwise you will waste a lot of bandwidth === arjenAU2 is now known as arjenAU [11:02] if they are related [11:02] (as in branches of each other) [11:02] awilkins: ack === Kissaki^0ff is now known as Kissaki === Kissaki is now known as Kissaki^0ff === statik` is now known as statik [12:38] 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/ === mrevell is now known as mrevell-lunch [12:45] Hi :) [12:45] vadi2: That's right, it would have imported several branches [12:45] vadi2: they're subdirectories of yorba4/ [12:45] ah. [12:46] Would there be a way to set the "ancestor" of a branch, in order to do some later merges ? [12:47] My problem is somewhat similar to http://fourkitchens.com/blog/2009/01/19/creating-common-branch-ancestry-hard-problem [12:48] I'm pretty new to bzr but I'm trying to manually rebuild a project history from { CVS, then BZR }, to BZR. [12:48] I finished the CVS part, in a new project, call it B, at rev 10. [12:48] The project contents at B rev 10 is identical to initial commit of project A. [12:48] I pushed a copy of previous branches, in project A into project B, branch B.A . [12:48] 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]