=== thumper-gym is now known as thumper
kate`can i bzr merge multiple things simultaneously, or must i merge one, commit, and then merge the next?04:56
=== spiv_ is now known as spiv
fullermd_kate`: You _can_.  Rarely a good reason for it though, IMO.06:17
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:26
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 two06:27
kate`they all contain independent files, too. no paths in common06:27
kate`ah. i see --force mentioned in 'help merge'06:29
kate`what an ominous name06:29
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:31
fullermd_Just so.06:32
spivIt's not a great option name, but it's familiar from some other tools like dpkg.06:34
spivOr even coreutils like rm, I suppose.06:35
kate`personally i'm terrible at naming things06: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 confusion06:35
spiv"You want me to connect to what?"06:36
spivI can imagine :)06:36
kate`"what's down" <- this never happened, but i wanted it to :)06:36
spivThere's always "what's up"06:37
kate`"nothing!" OH MY GOD PANIC06:37
fullermd_No, who's up.  What's in a second.06:38
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 histories06:40
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't06: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 interspersed06:41
kate`it's very tedious doing this, but it'll make me a happy bunny06:41
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 understand06:43
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 repository06:54
kate`how can that be?06:54
kate`if i checkout b's repository and look through the log, it only contains stuff under /b06:55
LarstiQkate`: might conflict on the root, that is, / being in a different location?07:38
kate`hm. i don't understand that; how can / be in a different location?07:44
spivkate`: like any other file/dir, it is possible to rename, and bzr will track that.  Not sure that'07:45
spivs the case here though; if you're able to pastebin a couple of lines of the conflict details it might help diagnose.07:45
kate`let me see if i can do that in an understandable manner...07:51
kate`lx.bzr contains /lx and all commits are under that path. -r2 is just mkdir for /lx07:54
kate`main.bzr has never had /lx at any point in its history07:54
kate`i don't understand what these conflict messages are telling me07:55
kate`lx.bzr was also created by svn-import07:58
kate`although with --layout=none, unlike main.bzr07:58
kate`huh. the range for -rx..y is inclusive, right?08:04
kate`geez. if i make that -r0..4 then "All changes applied successfully.". but 0 is an empty commit!08:05
=== mthaddon` is now known as mthaddon
fullermd_0..X is what you want for bringing together unrelated histories, since you want to merge everything from nothing to now.08:18
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 that08:26
fullermd_No, that's expected.  Your first commit is r1, so r0 is The Void.08:35
kate`aha, okay08:36
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 sense08:37
fullermd_So 0..4 is "everything from start to rev4"08:37
fullermd_Ditto for "diff -r0..1" etc.08:38
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:39
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 items08:40
kate`(i'm not talking about 0-indexed versus 1-indexed arrays)08:41
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 difficult08: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:42
kate`do you do that? i tend to assert everything is in the range i expect it to be08:43
fullermd_Or just stick random values in $[08:43
fullermd_But that really annoys people.08:43
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:44
kate`i prefer some sort of illusion of a scientific approach...08:47
kate`okay. here's the origional conflict problem i mentioned, which is confusing me still: http://codepad.org/cT2Rffdt08: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.bzr08:48
kate`libre.bzr only contains paths starting with /libre in its history, and lx.bzr only contains paths starting /lx08:49
fullermd_lx.br sure looks like it's touching all kinda of stuff in libre.08:49
kate`yeah, it does. but it's not!08:50
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:51
* kate` increases in confusion08:52
fullermd_My work here is done   8-}08:52
kate`can i show you a screenshot?08:53
kate`this is really silly08:53
fullermd_What's the provenance of the xyz.bzr's; are those from a svn conversion too?08:53
kate`they are, yes08:53
kate`they come from the same repository, actually. but svndumpfiltered to just include that path08: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:54
fullermd_UUID won't matter to bzr (in this meaning anyway)08:55
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.png08:56
fullermd_But, start with revs, just to be sure.  See what, if any, is common between libre and lx08:56
kate`revision '1' there is the empty revision i mentioned. no message, and no tree08:56
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 ok08:57
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:58
fullermd_No, pseudorandom uuid.08:59
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:00
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:01
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:02
kate`should these two suspiciously hashy looking numbers be identical? http://codepad.org/YPWcS04709:06
kate`that's the UUID from my svn dump09:07
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:10
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_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:12
kate`ok, cool. so all the fileids for 'bzr log -v --show-ids -r1..4' for lx.bzr are dinstinct from libre.bzr's fileids09:13
kate`now i'm wondering about revision-ids09:13
kate`...and the revision-ids are of the form svn-v4:UUID:rev where rev is the svn revision09: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:15
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 changesets09:16
kate`so the conflict is mistakenly looking at the wrong one...09:16
kate`i think09:16
fullermd_That wouldn't be confusing, that would be "nothing to do".09:17
fullermd_Check the missing output; if the revid's are the same, those revs wouldn't be in it.09:17
kate`well i'm just looking at log --show-ids, and i can see revision-id there09:18
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 dumps09:19
* kate` does so09: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::209:19
kate`revision-id: svn-v4:aadcad11-ff25-de11-bfba-00163e66cb13::109:19
kate`that's how they look09:19
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 done09:20
* kate` unsquirrels them09: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:20
kate`i think a --ignore-uuids option to svn-import wouldn't go amiss09:22
kate`the use-case is for when somebody has filtered a single svn dump into several distinct streams, and wishes to import each of those09:24
kate`it works :D09:25
kate`i modified the UUIDs in each of the streams i use to create lx.bzr and libre.lx, so that they're distinct09:26
* fullermd_ takes the credit.09:28
* kate` beams09:29
* mgz ducks09:29
mgzcareful with those beams!09:29
kate`ducks are probably more harmful09:29
fullermd_Hey, worry about your own mote before concerning yourself with... wait...09:29
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 hand10: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:27
kate`do my svn revision numbers matter?10:28
jelmerkate`: just reading up on backlog...10:32
=== mmrazik is now known as mmrazik|lunch
jelmerif 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
jelmerkate`: svn-import can importing into a repository that already has commits10:33
jelmerkate`: 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 matter10:34
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:35
jelmerkate`: the UUID does matter - bzr-svn will assume that two svn repositories with the same UUID have the same contents10:36
jelmerkate`: and it relies on this; the error you just saw is very likely caused by modification of the repository UUID10:36
kate`right. i modified my UUIDs to make them distinct10:36
jelmerah, if you made them distinct it shouldn't be an issue..10:36
kate`hm. so i want that new incoming dump to have the same UUID as my bzr repository, perhaps10:37
kate`possibly maybe10:37
kate`hm no. the UUID doesn't seem to relate to that Relative source revision -1 error10:43
kate`i think that might be due to my dump referring to a previous revision which is not present, because i filtered it out10:44
* kate` investigates10:44
kate`ah. i bet it's the Node-copyfrom-rev: references10:46
kate`i could just recreate these particular commits by hand, i suppose10:46
jelmerkate`: you also might want to import this into a svn repository rather than calling bzr svn-import on it directly10:52
kate`hm. and then how would i get those commits to my bzr repository?10:53
jelmerkate`: bzr svn-import works on svn repositories fine too10:55
jelmerkate`: in fact, if you give it a svn dumpfile, it will create a svn repository first, and then import from that svn repository10:56
kate`ok. but as far as i can see that would import from the very first revision --until something, right?10:56
jelmerkate`: yes, but it will skip any revisions already present in the bzr repository10:56
jelmerkate`: the behaviour (and code paths involved) are exactly the same as with a svn dump file10:56
kate`ooh. that's the bit i didn't know :)10:57
kate`the skipping part, that is10:57
=== 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

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!