[04:59] <jelmer> hi again :-)
[04:59] <jelmer> so, I just had a discussion with j-a-meinel
[05:00] <jelmer> he came up with something so obvious I hadn't thought about it yet
[05:00] <jelmer> ddaa: which is simply doing the upgrade by hand, when necessary
[05:01] <ddaa> okay, then what happens when you do the upgrade?
[05:01] <jelmer> then it breaks
[05:01] <ddaa> that does not look like a useful upgrade mechanism...
[05:02] <jelmer> there is no need to do the upgrade to v2 though, when v1 is working fine
[05:02] <jelmer> so you just keep at v1
[05:03] <ddaa> I think that still does not address my concern that an import using an old version, followed by an upgrade, and the same import using a new version of the plugin (w/o upgrade) may produce incompatible imports.
[05:03] <jamesh> what happens when someone else switches to v2 (e.g. you) and does a merge to SVN that we later scan?
[05:03] <jamesh> we'd need to version the properties used to record merges in that direction too
[05:05] <jelmer> the more complicated, but more complete solution, would be to use revision id aliases
[05:05] <jelmer> and, when you upgrade, set 'svn-v1:2@uuid-branch_path' to be equal to 'svn-v2:2@uuid-branch_path2' if it isn't affected by the bugfix
[05:07] <ddaa> jelmer: the revision id alias thing might be interesting, but until we have a working definition of how that should work, it's just handwaving.
[05:08] <ddaa> jelmer: so, say you have an branch that was imported from svn using svn-1.
[05:08] <jelmer> right
[05:09] <ddaa> a few people are working on branches derived from that one
[05:09] <ddaa> one of those people decides that he wants the benefit of svn-2
[05:10] <ddaa> he does "bzr svn upgrade" or something, and then what happens?
[05:11] <jelmer> ddaa:he ends up with a tree filled with svn-v2 revisions
[05:11] <jelmer> and can no longer exchange revisions with the others
[05:12] <ddaa> jelmer: that means that bzr upgrade is only possible when the tip of the branch is a svn-1 revision, right?
[05:12] <jelmer> yes
[05:13] <ddaa> okay, there's a specific reason why I avoided this suggestion before
[05:13] <ddaa> it means that we need provide an explicit upgrade knob in launchpad for svn imports
[05:13] <ddaa> and then give a list of every available svn import version for people to choose from
[05:14] <jelmer> Yes, that's correct. But there's not really a sane way around that without revision id aliases.
[05:15] <jelmer> and those are probably not going to be around soon
[05:15] <jelmer> ddaa: would it be problematic to have to require such an option?
[05:15] <jelmer> ddaa: Another thing you could do is simply provide one branch per mapping version
[05:16] <ddaa> it would make things much more complicated that they sould have to be, both the developer and for users.
[05:18] <jelmer> ddaa: or we could just stick with v1 until revision id aliases land. Other then bugfixes, what changes are waiting other than ignore lists, renames and externals ?
[05:18] <ddaa> and then you have data volume explosion issues when one user upgrades then merges back into svn
[05:18] <ddaa> BUGFIXES!!!
[05:18] <ddaa> bugfixes change the way a svn is converted to bzr, that needs to change the revision id to preserve referential integrity
[05:19] <ddaa> that it also true of temporary regressions in the conversion code
[05:20] <ddaa> if the bzr.dev folks say they are happy with violating referential integrity, I'll change my stance here, but right now it's a sacred cow.
[05:20] <jelmer> ddaa: What kind of bugs?
[05:21] <ddaa> jelmer: precisely that kind of bug
[05:21] <ddaa> the one you do not expect
[05:21] <ddaa> programmers make mistakes
[05:21] <ddaa> with arch imports, the deterministic id thing was a bit shaky
[05:21] <jamesh> any bug that would change how a revision is represented
[05:22] <ddaa> but it's already, because arch->bzr transition was essentially one off
[05:22] <ddaa> s/already/alright/
[05:22] <ddaa> and because the conversion was very trivial
[05:23] <ddaa> for svn, we have an ongoing, widely distributed, conversion process, integrity is much more critical
[05:23] <ddaa> it is also likely to get a lot more use
[05:23] <jelmer> sure, but what happens when you find a bug?
[05:24] <jelmer> can't you just upgrade only the branches affected by it?
[05:24] <ddaa> that's precisely the issue I do not have a satisfying solution for yet
[05:24] <ddaa> jelmer: and how do you know, when doing an import the first time, which format you should use?
[05:25] <jelmer> ddaa: if you do the import for the first time, always use the latest mapping since there are no users with upgrade issues
[05:25] <ddaa> by default, you would probably choose the latest, but that's wrong if other people are already using svn-1, that's wrong
[05:25] <jelmer> ddaa: how can people be using svn-v1 in that case?
[05:27] <ddaa> because they started using it before there was a svn-v2
[05:27] <ddaa> and they did not need/want to upgrade
[05:28] <ddaa> this "explicit upgrade and breaks interop inconditionally" is going to be a usability problem
[05:28] <jelmer> ddaa: how can they start using the importd branch when there was no import yet?
[05:30] <jelmer> ddaa: don't you do the same thing in launchpad at the moment? What do you do if you find a bug in the mapping?
[05:30] <ddaa> Fix the bug.
[05:30] <ddaa> in theory, at least
[05:30] <ddaa> it does not matter since the revision ids are arbitrary
[05:30] <jelmer> but what happens to existing revisions that are touched by the bug?
[05:30] <jelmer> so you just keep old revisions with the bug?
[05:30] <ddaa> yes
[05:31] <ddaa> under the theory that old history quickly loses value
[05:33] <jelmer> how about adding a "fake upgrade revision" ?
[05:33] <jelmer> so when you upgrade to v2, you fake a merge from a full v2 branch?
[05:37] <jelmer> hmm.. that causes a lot of history around, I guess
[05:42] <jelmer> unless you add the v2 revision as a ghost, I guess...
[05:44] <jelmer> yeah, that might actually work..
[05:44] <jelmer> ddaa: still there?
[05:44] <ddaa> partly
[05:45] <ddaa> I'm on a crunch to get native bzr imports up like right now
[05:45] <ddaa> Ideally, I think we would need to sit around some beer with some bzr.dev guy
[05:46] <ddaa> I feel like we are not getting through to one another
[05:46] <jelmer> I'm all for beer, but I think I'm onto something now...
[05:47] <ddaa> let's talk about that monday
[05:47] <jelmer> sure
[05:48] <jelmer> I'll just check it for obvious issues I've missed with John