monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Re: A better approach for cvs->mtn?


From: Bruce Stephens
Subject: [Monotone-devel] Re: A better approach for cvs->mtn?
Date: Tue, 21 Nov 2006 14:30:48 +0000
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.90 (gnu/linux)

Markus Schiltknecht <address@hidden> writes:

> Bruce Stephens wrote:
>> Larry Hastings <address@hidden> writes:
>>
>> [...]
>>
>>> So why not piggy-back on its success?  Skip "cvs2mtn"; instead
>>> create "svn2mtn", or enhance tailor's support for svn->monotone
>>> conversion as needed.  Then declare the first step in the official
>>> "cvs2mtn" conversion process is "convert to Subversion"!  This seems
>>> like the best bang-for-the-buck approach, getting rock-solid
>>> migration for both CVS /and/ SVN to monotone--which I'm guessing are
>>> the top two SCMs these days.
>
> Are you aware of my net.venge.monotone.cvsimport-branch-reconstruction
> branch? It's using the same algorithm cvs2svn 2.0 is going to use but
> targets monotone directly.

Yes.  I still haven't tried it yet, but I'm aware of it.

[...]

>> I'm not entirely convinced it'll help that much: if cvs2svn does a
>> good job then it'll be producing a subversion repository which is
>> also a wretched hive of inconsistency (with tags made up of files
>> from different branches, etc.).  Subversion has the advantage in
>> that it can represent such things, whereas other systems (like
>> monotone) just can't.
>
> That's one of the reasons why I didn't want to go that way. The
> other argument being that cvs_import already had most of the
> framework needed for the job.

Hmm, I guess that might make sense: doing the conversion directly
ought to offer a bit more flexibility than going from subversion
(since subversion has constructed revisions, and perhaps one can
compose different revisions which work better).

However, the basic problem remains, I think.  We've certainly got one
branch (in CVS) where, a month or two after branching, we decided that
some bits of the trunk were ready for the branch and we moved the
branch.

git's cvsimport complains that those files have a branch without a
symbol (where the branch symbol used to be).  I presume cvs2svn makes
a similar complaint since there's no way to reproduce that even in
subversion (there's no record of the branch symbol being moved) (I
don't remember whether there were warnings for that).

But anyway, you just can't represent that at all accurately in
something other than CVS or subversion: the branch happened at
different times for different files.  (And you can't represent the
moving branch at all, since the information's lost even to CVS.)  I
guess you just have to do the best you can, and duplicate the files
where necessary to make sure that the right files appear on the right
branches and tags?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]