[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: incremental conversion from other SCM to svn by vcp

From: <kfogel_at_collab.net>
Date: 2003-06-17 22:02:36 CEST

Barrie Slaymaker <barries@slaysys.com> writes:
> On Fri, Jun 13, 2003 at 10:28:37AM -0500, kfogel@collab.net wrote:
> > For example, if the file's first branch rev is 1.7.2.1, then you know
> > you can copy 1.7 (or rather, whatever svn revision corresponds to 1.7)
>
> VCP maintains the mapping of
>
> ( source fn, source rev # ) => ( dest fn, dest rev # )
>
> so it can get branch points like this correctly.

Actually, I'd like to understand some more about VCP's mapping of CVS
branches to Subversion branches (this mail is partly addressed to
Chia-liang Kao too).

It's clear that copy deduction is happening. For example, in
http://svn.openfoundry.org/svn/sympa/, I can see these branch
creations:

   rev 1893: root | 2003-06-11 20:42:58 -0500 (Wed, 11 Jun 2003) | 1 line
   Changed paths:
      A /branches/sympa-tt2 (from /trunk:1892)
   
   [...]

   rev 1553: root | 2002-10-16 21:31:57 -0500 (Wed, 16 Oct 2002) | 1 line
   Changed paths:
      A /branches/sympa-3_4-branch (from /trunk:1550)
   
   [...]

   rev 40: root | 2001-01-09 02:33:23 -0600 (Tue, 09 Jan 2001) | 1 line
   Changed paths:
      A /branches/sympa-3_0_1 (from /trunk:6)

   [...]

   rev 3: root | 2001-01-03 22:58:43 -0600 (Wed, 03 Jan 2001) | 1 line
   Changed paths:
      A /branches/cru (from /trunk:2)

and can see things get added to branches later, for example:

   ------------------------------------------------------------------------
   rev 1615: xclkao | 2003-06-13 02:39:18 -0500 (Fri, 13 Jun 2003) | 1 line
   Changed paths:
      A /branches/sympa-3_4-branch/src/etc/templates/fr/list_rejected.fr.tpl \
        (from /trunk/src/etc/templates/fr/list_rejected.fr.tpl:1614)
   
   copy from trunk to sympa-3_4-branch
   ------------------------------------------------------------------------
   rev 1614: salaun | 2002-11-13 19:26:20 -0600 (Wed, 13 Nov 2002) | 2 lines
   Changed paths:
      A /trunk/src/etc/templates/fr/list_rejected.fr.tpl
      A /trunk/src/etc/templates/us/list_rejected.us.tpl
      M /trunk/wwsympa/wwsympa.fcgi
   
   [reported by R. Salmon] Fix: rejection of pending lists was not coded
   ------------------------------------------------------------------------
   
But in the VCP code, I couldn't find the logic that a) decides which
revision to do the initial copy from and b) compensates for any
"wrong" material accidentally included by copying that revision. Such
material can arise, for example, when a branch was created on a set of
files/cvsrevs that were never all in HEAD at the same time in CVS. In
this situation, copying a single Subversion will wrongly include some
files/revs that aren't on the branch, and these would have to be
adjusted before the revision is committed (either by recopying from
elsewhere, or deleting).

I understand that the sympa/ repository may not have any such cases.
That's why I went looking in the VCP svn driver code itself, and then
elsewhere in VCP. The fact that I didn't find the logic I expected
might not mean anything. Perhaps VCP solves this problem in some way
I wasn't expecting -- that would be nice, in fact :-).

I was just writing about these and other edge cases in

   http://svn.collab.net/repos/svn/trunk/tools/cvs2svn/design-notes.txt

in the section entitled "Pass 4". The simplest algorithm I was able
to come up with to solve them is still quite complex -- so when I
didn't see something similar to it in VCP, I realized I needed to ask
the experts how VCP handles this stuff.

Thanks in advance for any enlightenment,
-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 17 22:50:24 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.