[04:56] <kate`> can i bzr merge multiple things simultaneously, or must i merge one, commit, and then merge the next?
[06:17] <fullermd_> kate`: You _can_.  Rarely a good reason for it though, IMO.
[06:26] <kate`> 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] <kate`> 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] <kate`> they all contain independent files, too. no paths in common
[06:29] <kate`> ah. i see --force mentioned in 'help merge'
[06:29] <kate`> what an ominous name
[06:31] <fullermd_> It used to be called --brute-force, but we decided to reserve that for the rumored "every-which-way" merge.
[06:31] <kate`> it's really "even though i have uncommitted changes", isn't it?
[06:32] <fullermd_> Just so.
[06:34] <spiv> It's not a great option name, but it's familiar from some other tools like dpkg.
[06:35] <spiv> Or even coreutils like rm, I suppose.
[06:35] <kate`> personally i'm terrible at naming things
[06:35] <kate`> i had a desktop with the hostname "what" at one company :/
[06:35] <kate`> "can i get to what?"
[06:35] <kate`> imagine the confusion
[06:36] <spiv> "You want me to connect to what?"
[06:36] <spiv> I can imagine :)
[06:36] <kate`> "what's down" <- this never happened, but i wanted it to :)
[06:37] <spiv> There's always "what's up"
[06:37] <kate`> "nothing!" OH MY GOD PANIC
[06:38] <fullermd_> No, who's up.  What's in a second.
[06:40] <kate`> 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] <kate`> 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] <kate`> 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] <kate`> it's very tedious doing this, but it'll make me a happy bunny
[06:43] <kate`> 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] <kate`> 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] <kate`> 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] <kate`> how can that be?
[06:55] <kate`> if i checkout b's repository and look through the log, it only contains stuff under /b
[07:38] <LarstiQ> kate`: might conflict on the root, that is, / being in a different location?
[07:44] <kate`> hm. i don't understand that; how can / be in a different location?
[07:45] <spiv> kate`: like any other file/dir, it is possible to rename, and bzr will track that.  Not sure that'
[07:45] <spiv> 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] <kate`> let me see if i can do that in an understandable manner...
[07:53] <kate`> http://codepad.org/v6n152NN
[07:54] <kate`> lx.bzr contains /lx and all commits are under that path. -r2 is just mkdir for /lx
[07:54] <kate`> main.bzr has never had /lx at any point in its history
[07:55] <kate`> i don't understand what these conflict messages are telling me
[07:58] <kate`> lx.bzr was also created by svn-import
[07:58] <kate`> although with --layout=none, unlike main.bzr
[08:04] <kate`> huh. the range for -rx..y is inclusive, right?
[08:05] <kate`> geez. if i make that -r0..4 then "All changes applied successfully.". but 0 is an empty commit!
[08:18] <fullermd_> 0..X is what you want for bringing together unrelated histories, since you want to merge everything from nothing to now.
[08:26] <kate`> 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] <fullermd_> No, that's expected.  Your first commit is r1, so r0 is The Void.
[08:36] <kate`> aha, okay
[08:37] <fullermd_> 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] <kate`> that makes sense
[08:37] <fullermd_> So 0..4 is "everything from start to rev4"
[08:38] <fullermd_> Ditto for "diff -r0..1" etc.
[08:39] <fullermd_> 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] <fullermd_> At least, everyone I've ever known does.  Otherwise, by rev 1000 or so your log message is gonna be _really_ long  ;>
[08:40] <kate`> 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] <kate`> (i'm not talking about 0-indexed versus 1-indexed arrays)
[08:42] <fullermd_> Everybody does  :)
[08:42] <kate`> 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] <fullermd_> 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] <kate`> do you do that? i tend to assert everything is in the range i expect it to be
[08:43] <fullermd_> Or just stick random values in $[
[08:43] <fullermd_> But that really annoys people.
[08:44] <fullermd_> 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] <kate`> i prefer some sort of illusion of a scientific approach...
[08:48] <kate`> okay. here's the origional conflict problem i mentioned, which is confusing me still: http://codepad.org/cT2Rffdt
[08:48] <fullermd_> That's why I imagine that the gnomes that sneak in during the night and break my code are wearing labcoats.
[08:48] <kate`> there you can see i merge in libre.bzr, commit it, and merge in lx.bzr
[08:49] <kate`> libre.bzr only contains paths starting with /libre in its history, and lx.bzr only contains paths starting /lx
[08:49] <fullermd_> lx.br sure looks like it's touching all kinda of stuff in libre.
[08:50] <kate`> yeah, it does. but it's not!
[08:51] <fullermd_> 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] <fullermd_> My work here is done   8-}
[08:53] <kate`> can i show you a screenshot?
[08:53] <kate`> this is really silly
[08:53] <fullermd_> What's the provenance of the xyz.bzr's; are those from a svn conversion too?
[08:53] <kate`> they are, yes
[08:54] <kate`> they come from the same repository, actually. but svndumpfiltered to just include that path
[08:54] <fullermd_> 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] <kate`> oh so i bet the repository's UUID is carried over...
[08:55] <fullermd_> UUID won't matter to bzr (in this meaning anyway)
[08:56] <fullermd_> 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] <kate`> 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] <fullermd_> But, start with revs, just to be sure.  See what, if any, is common between libre and lx
[08:56] <kate`> revision '1' there is the empty revision i mentioned. no message, and no tree
[08:57] <kate`> so i think i want to merge from -r1:4 (i don't want revisions 5 onwards)
[08:57] <fullermd_> (e.g., "cd libre.bzr ; bzr missing /where/ever/lx.bzr")
[08:57] <kate`> hm ok
[08:58] <fullermd_> 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] <fullermd_> And if that's the case, you've probably got fileids lining up somewhere you don't expect.
[08:58] <kate`> is a fileid a hash?
[08:59] <fullermd_> No, pseudorandom uuid.
[08:59] <kate`> hmmm
[09:00] <fullermd_> 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] <fullermd_> Which means a heuristic, which is such a nice polysyllabic word for "wrong".
[09:01] <fullermd_> Anyway.
[09:01] <fullermd_> 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] <fullermd_> 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] <kate`> should these two suspiciously hashy looking numbers be identical? http://codepad.org/YPWcS047
[09:07] <kate`> that's the UUID from my svn dump
[09:10] <fullermd_> That could be the way bzr-svn synthesizes fileids on import.
[09:10] <fullermd_> Once in bzr-land, it's not a svn rev or uuid or path anymore though, it's just an opaque string.
[09:10] <fullermd_> So those two are different.
[09:11] <kate`> hm. so the :%2Flx at the end is part of the string?
[09:11] <fullermd_> But look for that lx'd id across all the revs in lx.
[09:11] <fullermd_> Yes.
[09:12] <fullermd_> 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] <kate`> 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] <kate`> now i'm wondering about revision-ids
[09:15] <kate`> ...and the revision-ids are of the form svn-v4:UUID:rev where rev is the svn revision
[09:15] <kate`> so... both lx.bzr and libre.bzr contain the same revision-ids. i think these should be distinct, right?
[09:15] <fullermd_> 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] <fullermd_> Well, they are; if they weren't, there'd be nothing to merge.
[09:16] <kate`> 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] <kate`> so the conflict is mistakenly looking at the wrong one...
[09:16] <kate`> i think
[09:17] <fullermd_> That wouldn't be confusing, that would be "nothing to do".
[09:17] <kate`> hm
[09:17] <fullermd_> Check the missing output; if the revid's are the same, those revs wouldn't be in it.
[09:18] <kate`> well i'm just looking at log --show-ids, and i can see revision-id there
[09:19] <kate`> 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] <fullermd_> If you've got two revs that really have the same revid, and different contents, then you've got corrupted data.
[09:19] <kate`> revision-id: svn-v4:aadcad11-ff25-de11-bfba-00163e66cb13::2
[09:19] <kate`> revision-id: svn-v4:aadcad11-ff25-de11-bfba-00163e66cb13::1
[09:19] <kate`> that's how they look
[09:20] <kate`> (for both lx.bzr and libre.bzr)
[09:20] <fullermd_> 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] <kate`> right. that's what i've done
[09:20]  * kate` unsquirrels them
[09:20] <fullermd_> (it is of course Obviously(tm) a bug that bzr would do something as foolish as trust svn, but there ya go...)
[09:22] <kate`> i think a --ignore-uuids option to svn-import wouldn't go amiss
[09:24] <kate`> 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] <kate`> HAH!
[09:25] <kate`> it works :D
[09:26] <kate`> 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] <mgz> careful with those beams!
[09:29] <kate`> ducks are probably more harmful
[09:29] <fullermd_> Hey, worry about your own mote before concerning yourself with... wait...
[10:27] <kate`> 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] <kate`> 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] <kate`> do my svn revision numbers matter?
[10:32] <jelmer> kate`: just reading up on backlog...
[10:33] <jelmer> 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] <jelmer> kate`: svn-import can importing into a repository that already has commits
[10:34] <jelmer> kate`: do svn revision numbers matter for what specifically?
[10:34] <kate`> 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] <kate`> 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] <jelmer> kate`: the UUID does matter - bzr-svn will assume that two svn repositories with the same UUID have the same contents
[10:36] <jelmer> kate`: and it relies on this; the error you just saw is very likely caused by modification of the repository UUID
[10:36] <kate`> right. i modified my UUIDs to make them distinct
[10:36] <jelmer> ah, if you made them distinct it shouldn't be an issue..
[10:37] <kate`> hm. so i want that new incoming dump to have the same UUID as my bzr repository, perhaps
[10:37] <kate`> possibly maybe
[10:43] <kate`> hm no. the UUID doesn't seem to relate to that Relative source revision -1 error
[10:44] <kate`> 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] <kate`> ah. i bet it's the Node-copyfrom-rev: references
[10:46] <kate`> i could just recreate these particular commits by hand, i suppose
[10:52] <jelmer> kate`: you also might want to import this into a svn repository rather than calling bzr svn-import on it directly
[10:53] <kate`> hm. and then how would i get those commits to my bzr repository?
[10:55] <jelmer> kate`: bzr svn-import works on svn repositories fine too
[10:56] <jelmer> 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] <kate`> ok. but as far as i can see that would import from the very first revision --until something, right?
[10:56] <jelmer> kate`: yes, but it will skip any revisions already present in the bzr repository
[10:56] <jelmer> kate`: the behaviour (and code paths involved) are exactly the same as with a svn dump file
[10:57] <kate`> ooh. that's the bit i didn't know :)
[10:57] <kate`> the skipping part, that is