| === 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 | ||
| jelmer | hi again :-) | 04:59 |
|---|---|---|
| jelmer | so, I just had a discussion with j-a-meinel | 04:59 |
| 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:00 |
| === jamesh [n=james@82.109.136.116] has joined #launchpad-meeting | ||
| 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:01 |
| 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:02 |
| 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:03 |
| 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:05 |
| === ddaa thinks he's missing something obvious about this upgrade thing | ||
| 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:07 |
| ddaa | jelmer: so, say you have an branch that was imported from svn using svn-1. | 05:08 |
| jelmer | right | 05:08 |
| 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:09 |
| ddaa | he does "bzr svn upgrade" or something, and then what happens? | 05:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| jelmer | Yes, that's correct. But there's not really a sane way around that without revision id aliases. | 05:14 |
| 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:15 |
| ddaa | it would make things much more complicated that they sould have to be, both the developer and for users. | 05:16 |
| 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:18 |
| ddaa | that it also true of temporary regressions in the conversion code | 05:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| ddaa | because they started using it before there was a svn-v2 | 05:27 |
| ddaa | and they did not need/want to upgrade | 05:27 |
| 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:28 |
| 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:30 |
| ddaa | under the theory that old history quickly loses value | 05:31 |
| === SteveA [n=steve@82.109.136.116] has joined #launchpad-meeting | ||
| 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:33 |
| jelmer | hmm.. that causes a lot of history around, I guess | 05:37 |
| jelmer | unless you add the v2 revision as a ghost, I guess... | 05:42 |
| jelmer | yeah, that might actually work.. | 05:44 |
| jelmer | ddaa: still there? | 05:44 |
| ddaa | partly | 05:44 |
| 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:45 |
| 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:46 |
| ddaa | let's talk about that monday | 05:47 |
| jelmer | sure | 05:47 |
| jelmer | I'll just check it for obvious issues I've missed with John | 05:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!