| === 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 two | 06:27 |
| kate` | they all contain independent files, too. no paths in common | 06:27 |
| kate` | ah. i see --force mentioned in 'help merge' | 06:29 |
| kate` | what an ominous name | 06: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 |
| spiv | It's not a great option name, but it's familiar from some other tools like dpkg. | 06:34 |
| 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:35 |
| 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:36 |
| spiv | There's always "what's up" | 06:37 |
| kate` | "nothing!" OH MY GOD PANIC | 06: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 histories | 06: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'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: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 understand | 06: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 repository | 06: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 /b | 06:55 |
| LarstiQ | kate`: 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 |
| 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:45 |
| kate` | let me see if i can do that in an understandable manner... | 07:51 |
| kate` | http://codepad.org/v6n152NN | 07:53 |
| 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:54 |
| kate` | i don't understand what these conflict messages are telling me | 07:55 |
| kate` | lx.bzr was also created by svn-import | 07:58 |
| kate` | although with --layout=none, unlike main.bzr | 07: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 that | 08:26 |
| fullermd_ | No, that's expected. Your first commit is r1, so r0 is The Void. | 08:35 |
| kate` | aha, okay | 08: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 sense | 08: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 items | 08: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 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:42 |
| 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: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/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:48 |
| 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: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 confusion | 08:52 | |
| fullermd_ | My work here is done 8-} | 08:52 |
| 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:53 |
| 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: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.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: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 ok | 08: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 |
| kate` | hmmm | 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_ | 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: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/YPWcS047 | 09:06 |
| kate` | that's the UUID from my svn dump | 09: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_ | Yes. | 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 fileids | 09:13 |
| kate` | now i'm wondering about revision-ids | 09:13 |
| 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: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 changesets | 09:16 |
| kate` | so the conflict is mistakenly looking at the wrong one... | 09:16 |
| kate` | i think | 09:16 |
| 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:17 |
| kate` | well i'm just looking at log --show-ids, and i can see revision-id there | 09: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 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: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 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:20 |
| kate` | i think a --ignore-uuids option to svn-import wouldn't go amiss | 09: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 those | 09:24 |
| kate` | HAH! | 09:25 |
| kate` | it works :D | 09:25 |
| 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:26 |
| * fullermd_ takes the credit. | 09:28 | |
| * 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... | 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 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:27 |
| kate` | do my svn revision numbers matter? | 10:28 |
| jelmer | kate`: just reading up on backlog... | 10:32 |
| === mmrazik is now known as mmrazik|lunch | ||
| 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:33 |
| 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: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 |
| 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:36 |
| 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:37 |
| kate` | hm no. the UUID doesn't seem to relate to that Relative source revision -1 error | 10:43 |
| 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:44 | |
| 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:46 |
| jelmer | kate`: you also might want to import this into a svn repository rather than calling bzr svn-import on it directly | 10:52 |
| kate` | hm. and then how would i get those commits to my bzr repository? | 10:53 |
| jelmer | kate`: bzr svn-import works on svn repositories fine too | 10:55 |
| 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:56 |
| kate` | ooh. that's the bit i didn't know :) | 10:57 |
| kate` | the skipping part, that is | 10: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!
