Re: [Monotone-devel] quick&dirty CVS export

[Daniel Carosone]

On Sat, Oct 07, 2006 at 03:44:18PM +0200, Lapo Luchini wrote:
> While brooding over FreeBSD's "wanted features ni a VCS" I found
> myself thinking about one of the few we do not have "real" support no
> the mainline yet: FeatureCVSExport.
> I also talked quite a bit about it with a friend of mine and he told
> me that probably that "wanted" CVSExport feature doesn't necessarily
> mean "every single revision should be also on CVS as accurate as
> possible", as CVS would be used only during migration anyway, and
> would probably be considered as "legacy support" anyway.

Agreed. The requirement and example is worded carefully to allow this.
It seems that a real export, that recreated a CVS history from
scratch, rather than a two-way sync, would be acceptable, though "it
would be nice" if it didn't also break existing user checkouts.

One simple way to do that might just be to start all the new cvs
versions from 2.x?

This touches closely on one of the NetBSD requirements we've been
discussing too, which I had been looking at mostly as a need for
partial pull: how to help end users following (say) a release branch
update quickly, without needing to keep all of history around.  A
lightweight CVS export (that didn't need any further import) would
address this need to, and I think that's mostly what FreeBSD are after
here.

> I thought of a quick&dirty way to export a linear CVS history out of a
> (possibly very active and thus containing often various heads) branch:

Yep, I had something essentially similar in mind, but a little more
explicit: create a monotone branch for the cvs export, that should
have a linear history.  Merge each of the changes on the main branch
to it, just in the order you did.  If the merge fails with a conflict,
skip that change and try again from a descendant, eventually hitting a
merge that resolves the conflict.  Then keep this linear branch in
sync with CVS (two way if you like, treating it as a vendor branch for
changes coming from CVS).

I had a diagram showing basically this approach in a recent discussion
about cvs_sync and using attrs to track the cvs ids.  So I think it's
quite doable.

A small terminology nit with your example: once you've exported a
merge node that's a descendent of A, all of its descendants also
inherit A even if there are multiple heads.  You need to reset which
node you're calling A, basically whenever a merge node is the unique
branch head at the time you export. If you later learn of more nodes
that circumvent the path through this head, CVS won't see them until
they're merged back - as you intended.

If you implement the (essentially same) algorithm as I describe, using
monotone to record revisions exported to CVS in their own branch, then
keeping track of A is automatic: it's just the LCA of the two
branches.

> If the multiple-heads states are not very long (and everyone good
> interests is in keeping them short, unless they're doing one of those
> rare "revolutions in the source code") the CVS final tree doesn't seem
> very unreasonable to me.

It's fine, those revolutions should happen in a side branch anyway.
Regardless of whether the side branch is also exported to CVS, the
merge back to mainline will appear as a big summarised change like
this - even if it had all been done natively in CVS.  

CVS doesn't record merge history (whether it was in the working dir on
update-before-commit, or of a named branch) and therein lies the basis
of this approach.  Monotone does record both microbranch and
fullbranch history, so we can treat *all* of those as a side history
to a set of merges into a linear CVS history.   If we do that
explicitly in monotone as we sync, rather than as an artifact of the
way we export, we have everything we need to merge in later cvs
changes too.

--
Dan.

pgpNdPtIr8Wrs.pgp
Description: PGP signature