=== thumper-gym is now known as thumper [04:56] can i bzr merge multiple things simultaneously, or must i merge one, commit, and then merge the next? === spiv_ is now known as spiv [06:17] kate`: You _can_. Rarely a good reason for it though, IMO. [06:26] fullermd_, in this case i started development with three independent repositories, in parallel. they're all of equal status; i want to move them all to the same repository (and discard their origional repositories) [06:27] so i thought it'd make sense to merge them all simultaneously if i can, because there's no reason i'd order one over the other two [06:27] they all contain independent files, too. no paths in common [06:29] ah. i see --force mentioned in 'help merge' [06:29] what an ominous name [06:31] It used to be called --brute-force, but we decided to reserve that for the rumored "every-which-way" merge. [06:31] it's really "even though i have uncommitted changes", isn't it? [06:32] Just so. [06:34] It's not a great option name, but it's familiar from some other tools like dpkg. [06:35] Or even coreutils like rm, I suppose. [06:35] personally i'm terrible at naming things [06:35] i had a desktop with the hostname "what" at one company :/ [06:35] "can i get to what?" [06:35] imagine the confusion [06:36] "You want me to connect to what?" [06:36] I can imagine :) [06:36] "what's down" <- this never happened, but i wanted it to :) [06:37] There's always "what's up" [06:37] "nothing!" OH MY GOD PANIC [06:38] No, who's up. What's in a second. [06:40] i've 20 or so svn repositories i'm converting to bzr. some of them have (or rather would have, if svn could express it) pretty complex histories [06:41] so i'm converting them by cutting them apart, and splicing them back together with manually-inserted branches and merges and things, which is what i would have done at the time, but couldn't [06:41] that way i'll have a history which actually shows what i was intending, rather than just one linear changelog with unrelated things interspersed [06:41] it's very tedious doing this, but it'll make me a happy bunny [06:43] for a few i reorganised the top-level layout occasionally, and (as in the case i just mentioned with the three seperate repositories being joined), various other things automated tools don't understand [06:54] ok. so i'm confused. if i have a repository which contains /a, and another which contains /b, i would expect that i can merge both to a checkout of another copy (which itself has neither /a nor /b) [06:54] but issuing those two seperate merges, i'm told i have conflicts for paths under /a, when i merge in b's repository [06:54] how can that be? [06:55] if i checkout b's repository and look through the log, it only contains stuff under /b [07:38] kate`: might conflict on the root, that is, / being in a different location? [07:44] hm. i don't understand that; how can / be in a different location? [07:45] kate`: like any other file/dir, it is possible to rename, and bzr will track that. Not sure that' [07:45] s the case here though; if you're able to pastebin a couple of lines of the conflict details it might help diagnose. [07:51] let me see if i can do that in an understandable manner... [07:53] http://codepad.org/v6n152NN [07:54] lx.bzr contains /lx and all commits are under that path. -r2 is just mkdir for /lx [07:54] main.bzr has never had /lx at any point in its history [07:55] i don't understand what these conflict messages are telling me [07:58] lx.bzr was also created by svn-import [07:58] although with --layout=none, unlike main.bzr [08:04] huh. the range for -rx..y is inclusive, right? [08:05] geez. if i make that -r0..4 then "All changes applied successfully.". but 0 is an empty commit! === mthaddon` is now known as mthaddon [08:18] 0..X is what you want for bringing together unrelated histories, since you want to merge everything from nothing to now. [08:26] well r0 looks to be a completely empty commit, i think as a side effect of the filtering i did with svn... so i was trying to elide that [08:35] No, that's expected. Your first commit is r1, so r0 is The Void. [08:36] aha, okay [08:37] Remember that revisions are _states_, not _changes_. So asking for "merge -r0..1" means "merge the change from state 0 (nothing) to state 1 (first commit). [08:37] that makes sense [08:37] So 0..4 is "everything from start to rev4" [08:38] Ditto for "diff -r0..1" etc. [08:39] We all kinda fudge things when it comes to 'log' of course, since in your log for rev X you're really describing the change from (X-1) to X rather than the state X which is what you're actually recording, but... [08:39] At least, everyone I've ever known does. Otherwise, by rev 1000 or so your log message is gonna be _really_ long ;> [08:40] you know, if there's one thing i consistently get wrong with programing - in any language - it's off-by-one errors when i'm thinking about sets of items, iterating through them, and what i consider an item or the distance between items [08:41] (i'm not talking about 0-indexed versus 1-indexed arrays) [08:42] Everybody does :) [08:42] like for example if i'm implementing binary search, and i need to consider the middle element of a range. i find that sort of thing super difficult [08:42] That's why you write scripts to help you debug, that just load up your program and add a "-1" to a random line to see if it helps. [08:43] do you do that? i tend to assert everything is in the range i expect it to be [08:43] Or just stick random values in $[ [08:43] But that really annoys people. [08:44] Not really. But I've thought about it. Mostly avoided it because I was afraid it would sooner or later _work_, and that would just drive me insane. [08:47] i prefer some sort of illusion of a scientific approach... [08:48] okay. here's the origional conflict problem i mentioned, which is confusing me still: http://codepad.org/cT2Rffdt [08:48] That's why I imagine that the gnomes that sneak in during the night and break my code are wearing labcoats. [08:48] there you can see i merge in libre.bzr, commit it, and merge in lx.bzr [08:49] libre.bzr only contains paths starting with /libre in its history, and lx.bzr only contains paths starting /lx [08:49] lx.br sure looks like it's touching all kinda of stuff in libre. [08:50] yeah, it does. but it's not! [08:51] The mods in the files suggest bzr thinks they're related files. The path conflict suggests an unrelated file with the same name. [08:52] * kate` increases in confusion [08:52] My work here is done 8-} [08:53] can i show you a screenshot? [08:53] this is really silly [08:53] What's the provenance of the xyz.bzr's; are those from a svn conversion too? [08:53] they are, yes [08:54] they come from the same repository, actually. but svndumpfiltered to just include that path [08:54] So, there's apparently only 4 revs in lx.bzr (at least, only 4 you care about here), so I'd start looking there. [08:54] oh so i bet the repository's UUID is carried over... [08:55] UUID won't matter to bzr (in this meaning anyway) [08:56] The important thing to bzr will be the revs themselves, and since you're forcing the range from 0 that's probably not at the forefront. What will be is fileids. [08:56] this is the log for lx.bzr, which i just checked out so i can 'bzr explore' it: http://dioptre.org/tmp/lx-bzr.png [08:56] But, start with revs, just to be sure. See what, if any, is common between libre and lx [08:56] revision '1' there is the empty revision i mentioned. no message, and no tree [08:57] so i think i want to merge from -r1:4 (i don't want revisions 5 onwards) [08:57] (e.g., "cd libre.bzr ; bzr missing /where/ever/lx.bzr") [08:57] hm ok [08:58] If bzr really thinks they're unrelated (which I wouldn't unsuspect, but might as well be sure) both lists will start from rev 1 onward. [08:58] And if that's the case, you've probably got fileids lining up somewhere you don't expect. [08:58] is a fileid a hash? [08:59] No, pseudorandom uuid. [08:59] hmmm [09:00] But the svn conversion complicates (or simplifies) things in that it'll try to take hints from svn about what files may be the same. [09:00] Which means a heuristic, which is such a nice polysyllabic word for "wrong". [09:01] Anyway. [09:01] Looking at something like "log -v --show-ids -r0..4" for lx might give some hints, as may poking around 'ls --show-ids' in the current of libre. [09:02] It seems at a glance the fruitful course would be poking around those two and ignoring trunk (though that could be wrong, and it could be a trunk/lx conflict, but it _seems_ like libre/lx) [09:06] should these two suspiciously hashy looking numbers be identical? http://codepad.org/YPWcS047 [09:07] that's the UUID from my svn dump [09:10] That could be the way bzr-svn synthesizes fileids on import. [09:10] Once in bzr-land, it's not a svn rev or uuid or path anymore though, it's just an opaque string. [09:10] So those two are different. [09:11] hm. so the :%2Flx at the end is part of the string? [09:11] But look for that lx'd id across all the revs in lx. [09:11] Yes. [09:12] bzr's standard generation ends up looking something like "basename-datestamp-randombits". The svn conversion looks like rev@uuid:path. But either way, it's functionally opaque; just a pile of bytes to identify it. [09:13] ok, cool. so all the fileids for 'bzr log -v --show-ids -r1..4' for lx.bzr are dinstinct from libre.bzr's fileids [09:13] now i'm wondering about revision-ids [09:15] ...and the revision-ids are of the form svn-v4:UUID:rev where rev is the svn revision [09:15] so... both lx.bzr and libre.bzr contain the same revision-ids. i think these should be distinct, right? [09:15] That seems odd. the lx merge is modifying libre/src/Makefile and libre/src/cli/main.c etc, so it apparently has some file that matches that file-id. [09:16] Well, they are; if they weren't, there'd be nothing to merge. [09:16] right. i think merge is confused because the revision-id for the incoming lx changeset is the same as the revision-id as one of libre.bzr's changesets [09:16] so the conflict is mistakenly looking at the wrong one... [09:16] i think [09:17] That wouldn't be confusing, that would be "nothing to do". [09:17] hm [09:17] Check the missing output; if the revid's are the same, those revs wouldn't be in it. [09:18] well i'm just looking at log --show-ids, and i can see revision-id there [09:19] okay. well my best hypothesis so far is that the UUID being the same is causing some problem *somehow*, and i can test that easily enough by substuting different UUIDs for each of my dumps [09:19] * kate` does so [09:19] If you've got two revs that really have the same revid, and different contents, then you've got corrupted data. [09:19] revision-id: svn-v4:aadcad11-ff25-de11-bfba-00163e66cb13::2 [09:19] revision-id: svn-v4:aadcad11-ff25-de11-bfba-00163e66cb13::1 [09:19] that's how they look [09:20] (for both lx.bzr and libre.bzr) [09:20] If you made two different svn dumps with the same uuid and different contents, that would be one way to get things all squirreled up. [09:20] right. that's what i've done [09:20] * kate` unsquirrels them [09:20] (it is of course Obviously(tm) a bug that bzr would do something as foolish as trust svn, but there ya go...) [09:22] i think a --ignore-uuids option to svn-import wouldn't go amiss [09:24] the use-case is for when somebody has filtered a single svn dump into several distinct streams, and wishes to import each of those [09:25] HAH! [09:25] it works :D [09:26] i modified the UUIDs in each of the streams i use to create lx.bzr and libre.lx, so that they're distinct [09:28] * fullermd_ takes the credit. [09:29] * kate` beams [09:29] * mgz ducks [09:29] careful with those beams! [09:29] ducks are probably more harmful [09:29] Hey, worry about your own mote before concerning yourself with... wait... [10:27] ok. so now i'm 'svn-import'ing another dump which i'd like to continue linearly in my bzr repository's history, just as if i commit things by hand [10:27] i think i checked before, but i'm still not sure. can i svn-import into a repository which already has some commits? [10:28] do my svn revision numbers matter? [10:32] kate`: just reading up on backlog... === mmrazik is now known as mmrazik|lunch [10:33] if you modified the UUID in a svn repository to have the same UUID as another svn repository that doesn't have the exact same contents, you're very likely to break bzr-svn (if not now, then you'll hit bumps at some point in the future) [10:33] kate`: svn-import can importing into a repository that already has commits [10:34] kate`: do svn revision numbers matter for what specifically? [10:34] jelmer, this is a one-way conversion of an svn repository which i want to be store henceforth canonically in bzr - so i think the UUID doesn't matter [10:35] ok. well svn-import of a svn dump which has changesets that mv around a few files (these files are already present in my bzr repository): bzr: ERROR: subvertpy.SubversionException: ('Relative source revision -1 is not available in current repository', 160006) [10:36] kate`: the UUID does matter - bzr-svn will assume that two svn repositories with the same UUID have the same contents [10:36] kate`: and it relies on this; the error you just saw is very likely caused by modification of the repository UUID [10:36] right. i modified my UUIDs to make them distinct [10:36] ah, if you made them distinct it shouldn't be an issue.. [10:37] hm. so i want that new incoming dump to have the same UUID as my bzr repository, perhaps [10:37] possibly maybe [10:43] hm no. the UUID doesn't seem to relate to that Relative source revision -1 error [10:44] i think that might be due to my dump referring to a previous revision which is not present, because i filtered it out [10:44] * kate` investigates [10:46] ah. i bet it's the Node-copyfrom-rev: references [10:46] i could just recreate these particular commits by hand, i suppose [10:52] kate`: you also might want to import this into a svn repository rather than calling bzr svn-import on it directly [10:53] hm. and then how would i get those commits to my bzr repository? [10:55] kate`: bzr svn-import works on svn repositories fine too [10:56] kate`: in fact, if you give it a svn dumpfile, it will create a svn repository first, and then import from that svn repository [10:56] ok. but as far as i can see that would import from the very first revision --until something, right? [10:56] kate`: yes, but it will skip any revisions already present in the bzr repository [10:56] kate`: the behaviour (and code paths involved) are exactly the same as with a svn dump file [10:57] ooh. that's the bit i didn't know :) [10:57] the skipping part, that is === mmrazik|lunch is now known as mmrazik === verterok` is now known as verterok === rvba` is now known as rvba === mmrazik is now known as mmrazik|afk === mmrazik|afk is now known as mmrazik === deryck is now known as deryck[lunch] === deryck[lunch] is now known as deryck === ubot5` is now known as ubot5