----- Original Message ---- > From: Michael Stahl <[email protected]> > On 14.07.2011 18:03, Michael Stahl wrote: > > On 09.07.2011 07:57, Greg Stein wrote: > >> Once the tags are properly marked, then we can start testing the > >> conversion to Subversion. Please note, however: the hg conversion > >> script does *not* process tags. We will have to write that. We will > >> also have to somehow manage construction of branches. We may also have > >> to update the conversion tool to properly handle the "merge" > >> changesets that Hg records. > > > > after looking at the HG convert svn_sink a little, this looks rather > > difficult to me. > > > > well, tags should be easy. > > > > but how to reconstruct the branching is kind of unclear to me. > > the first ~260k changesets are linear and were initially taken from SVN, > > so that shouldn't be a problem. > > but then there are lots of HG merge changesets. > > unfortunately it seems none of the tools that convert from HG or git to SVN >can create SVN branches with SVN mergeinfo (necessary in order to be able to >merge the branches back into the trunk). > > there are some tools to convert from git that can create SVN branches, but >they leave out the SVN mergeinfo; apparently the intent is to maintain a >read-only mirror... > > > in the HG repo there is sort of a "master" history that is basically a > > sequence of CWS integration merge changesets, with the occasional > > masterfix thrown in. > > but this is not explicit: these are all just merges with 2 parents, and > > it's not guaranteed which of these 2 is the CWS and which the master. > > basically the requirement is to convert one of the thousands of paths > > through this DAG from the common ancestor revision ~260k to revision > > c904c1944462 (OOO340 head) into a SVN trunk. > > to be more specific, the last revision from OOo SVN was the tag >"last_svn_milestone" (263206 d0058b5891eb) > (which is not actually a common ancestor, as some CWSes are based on older >milestones) > > the following merge commits are those on the DEV300 master/"trunk" where > i've >noticed the "follow the first parent" heuristic would fail, and the second >parent (after the arrow) should be taken instead. > > 90552a19cdc4 -> dae1ffc5c15d > 9572400cd241 -> ce1b12199f72 > c33f611c4373 -> 5d0c069f2570 > 13b3d2dae916 -> 62bf02dff30b > 37dc1e423a1e -> 664c5f3a9291 > > > basically we have these options for converting to SVN: > > 1. convert full history > requires writing tool to create SVN branches and mergeinfo > > 2. convert trunk only, using follow-first-parent heuristic > with hacks where we want to follow second parent instead > > 3. no history in SVN, just check in OOO340 tip > > option 1. seems to be too much effort to me, and would have to be > implemented >by a real SVN wizard. > > option 2. requires some effort, but should be doable; we still lose all CWS >internal history though (e.g. CWS undoapi becomes a single 57,788 line >changeset against 562 files). > > after thinking about it for a while, a trunk-only history in SVN doesn't > seem >to be all that useful to me (you need to go over the network to access >something incomplete...). > > far more useful would be to have a read-only HG/git repository available > that >contains the _full_ history and all open CWS branches, which can be cloned >and >examined off-line. > > opinions? >
I at least lurk on the SVN and TSVN lists where similar kinds of questions come up on occasion as people convert to/from SVN. #1 is probably simpler than one may think as it could be a basic shell script that simply iterates over every revision in HG and makes the equivalent commit to SVN. People have used that approach to convert CVS repositories to SVN where the conversion was not very simple. This method does maintain all the merge info for branching. For comparisons sake, cvs2svn extracts the data from the CVS/RCS repository and builds an SVN Dump File with the equivalent data, which I doubt contains the merge info, to be loaded into SVN. Both processes are rather time-consuming. If this was desired, then I would suggest whoever spearheads this talk with the SVN and HG developers. I don't know what the API/interface for HG is, but SVN has a nice library that can be utilized if a tool was being built. Further the cvs2svn project may be of interest as they do support cvs2hg, so it may provide at least some insight into a hg2svn tool. $0.02 Ben
