monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] About the recent change of cvs_import...


From: Nathaniel Smith
Subject: Re: [Monotone-devel] About the recent change of cvs_import...
Date: Fri, 20 May 2005 11:50:20 -0700
User-agent: Mutt/1.5.9i

On Fri, May 20, 2005 at 07:35:03AM +0200, Richard Levitte - VMS Whacker wrote:
> Hi,
> 
> I just started playing with cvs_import to move some projects currently
> handled with CVS to monotone.
> 
> Imagine my surprise when the different branches weren't connected!
> And I was sure an earlier experiment had handled my branches properly.
> 
> When I check around, I noticed that it was a recent change in
> rcs_import.cc, and it comes with a huge comment explaining the whole
> thing.  I can understand the reasons to do it in this new way, since
> it's quite a lot of work figuring out where the branch point is.

Err, crud.  You're right.  I hadn't actually looked at graydon's
change yet, thanks for pointing it out... This change is a problem,
because it means that we _have_ to support file suturing, in all its
icky glory, right from the get-go.  Or else tell people that have
imported from cvs that sorry, they just can't do any merging, which
would be terrible.

(cf.
http://lists.gnu.org/archive/html/monotone-devel/2005-05/msg00326.html
)

Surely we can do better than this?  I _think_ cvs2svn does something
more sensible here, and it's solving exactly the same problem we are;
if someone could figure out how it handles this sort of wackiness,
that would be very helpful.

(I wonder how hard it would be to fork cvs2svn to make a cvs2monotone
that worked the same way.  It probably couldn't handle large
repositories very well and would be very slow compared to cvs_import
-- Danny Berlin, when using cvs2svn to convert the gcc repository,
ended up using monotone's cvs_import code to pull the file data itself
out -- but it might be helpful while we finish shaking out the corner
cases of cvs_import.)

It also seems like it would be _better_ than the current thing to just
make a guess at the branch-point -- basically, calculate exactly the
same manifests we calculate now, but instead of rooting them at the
tail ancestor, root them at the first commit on the branch we see.
This sort of "best effort" thing should be exactly correct for the
common case where people haven't done really clever things with their
CVS branches, and wouldn't be too bad for case where they have,
either.

-- Nathaniel

-- 
"On arrival in my ward I was immediately served with lunch. `This is
what you ordered yesterday.' I pointed out that I had just arrived,
only to be told: `This is what your bed ordered.'"
  -- Letter to the Editor, The Times, September 2000




reply via email to

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