Re: [Monotone-devel] workspace migration improvements - no more database

[Daniel Carosone]

On Wed, Sep 06, 2006 at 11:59:33AM +0200, Christof Petig wrote:
> Daniel Carosone schrieb:
> > You need to know this, but do you actually need to store this
> > explicitly?  If you set an attr in revision N at sync time to the cvs
> > id, and then in a child revision M there's a local commit that changes
> > content, you can see this from the rosters of M and N where there are
> > different contents for the same node and attr value.  Note that those
> > revisions will be marked, too.
> 
> If I understand this correctly you have to traverse the revision tree to
> find revision N (which is the last synced revision for this file) for
> each file separately.

Sure, but it's the same traversal you'll do right after that to merge
the local changes with the CVS ones... which brings me to the point
that cvs_sync should probably commit new incoming cvs revisions as
direct children of the last sync, then the user can merge those with
local changes like any other incoming heads:


     A = cvs 1.1
     |
     B = cvs 1.2
    /|
   L C = cvs 1.3
   | |
   | D = cvs 1.4
   |/|
   M E = cvs 1.5
   |/
   N             (merge to pass cvs up-to-date check)
    \
     F = cvs 1.6 (push N, new rev to update attr for cvs commit)

This keeps the linear CVS history linear, makes local changes obvious,
and handles merging (and conflicts) of them exactly like any other
changes. This sort of thing is only going to make even more sense when
cvs_sync follows multiple connected cvs branches.

Notice how the attr values in M and N automatically describe the CVS
revision they were last based from, without necessarily implying exact
content equivalence.  It's all about what we define the attr to mean.

> I am not per se against using attributes as the preferred storage method
> for sync information, I just see no way to get this done efficiently.

The nodes in question have markings for the attr and the content to
find them quickly, and are going to need to be fetched regardless, so
one or the other step will put them in the cache.  Ah, but I forgot
you're now working externally, so I can see some of your concern in
trying to find this via automate stdio. Which means that interface
should be extended to answer questions like 'what rev last set this
attr' efficiently if needed.

Anyway, the above should also minimise or even eliminate the issue, if
you always start against a rev you know was fully in sync with cvs.
You can mark this with a cert on the whole revision, which says the
attrs can be trusted for cvs equivalence.

--
Dan.

pgpAzM4vJPf52.pgp
Description: PGP signature