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