Re: [Monotone-devel] cvs import

From: Daniel Carosone <dan@geek.com.au>
Date: Sep 13, 2006, 23:52 UTC
Message-ID: <20060913235227.GW29625@bcd.geek.com.au>
In-Reply-To: <20060913232139.GU29625@bcd.geek.com.au>

On Thu, Sep 14, 2006 at 09:21:39AM +1000, Daniel Carosone wrote:

Show 7 quoted lines

> > I have no particular idea on how to handle tags and branches here;
> > I've never actually wrapped my head around CVS's model for those :-).
> > I'm not seeing any obvious problem with handling them, though.
> 
> Tags could be modelled as another 'event' in the file graph, like a
> commit. If your frontier advances through both revisions and a 'tag
> this revision' event, the same sequencing as above would work.

Likewise, if we had "file branched" events in the file lifeline (based on the rcs id's), then we would be sure to always have a monotone revision that corresponded to the branching event, where we could attach the revisions in the branch.

Because we can't split tags, and can't split branch events, we will end up splitting file commits (down to individual commits per file) in order to arrive at the revisions we need for those.

Because tags and branches can be across subsets of the tree, we gain some scheduling flexibility about where in the reconstructed sequence they can come.

Many well-managed CVS repositories will use good practices, such as having a branch base tag. If they do, then they will help this algorithm produce correct results.

Once we have a branch with a base starting revision, we can pretty much treat it independently from there: make a whole new set of file lifelines along the RCS branches and a new frontier for it.

-- Dan.