Re: [Monotone-devel] New cvssync.attrs branch

[Nathaniel Smith]

On Mon, Mar 19, 2007 at 10:48:56PM +1100, William Uther wrote:
> At the moment I'm using similar attributes to the .refactor branch to  
> store the sync information (<dom>:module, <dom>:root and <dom>:branch  
> on the root dir

Presumably this means "root dir (or subdirectories)", since it is
actually reasonable in cvs for a tree to span several modules?

> then <dom>:revision, <dom>:sha1 and <dom>:keywords  
> on individual files.  <dom> is the --domain argument and defaults to  
> "cvs").

Is your handling of :revision etc. robust against people who swap
files around?  I.e.:
   mtn rev 1:    foo.c   cvs:revision=1.1
                 bar.c   cvs:revision=1.3
     <rename rename, ignoring this cvs gunk>
   mtn rev 2:    foo.c   cvs:revision=1.3
                 bar.c   cvs:revision=1.1
Where rev 1 is marked as in sync?

The sha1 attr seems pointless to me.  (Christof had it in there for
support of "takeover", see below.)

Maybe instead of <dom> it should be "cvs[-<arbitrary suffix, usually
empty>]"?  I.e., just requiring that <dom> always start with cvs, for
clarity?

> And I'm using my own simple cert to mark valid sync: mtn-cvs- 
> sync=<dom>.  Is there some other standard I should change to?

Umm, I dunno, that doesn't strike me as the obviously correct name,
but I have no suggestions in particular.

> The new branch passes most of the cvssync unit tests (I haven't  
> updated any of the 'takeover' commands yet, and the two more complex  
> ones of those fail).  The new branch passes more of the tests on  
> basic push/pull functionality than the .refactor branch.
> 
> Does anyone use the takeover functionality?  I'm tempted to take it  
> out rather than fix it.

We had this argument at the summit too :-).  The use case for takeover
is: I have a project I am working on, I get on the plane, I discover
that, doh, I want to commit.  I could do that if only I had used
cvssync to put this project into monotone to start with, but now it is
too late.  Except -- takeover to the rescue!  I can put my existing
workspace into monotone, even though I am offline.

It does seem like a valid use case.  Personally it seems like exactly
the sort of thing you can defer until version 2 (or whatever we're up
to now), I prefer code that solves 90% of use cases and is usable than
code that solves 100% of use cases just... not yet.  But whatever.

It's actually not too hard to make work -- you take the CVS checkout,
you stick all the files in monotone, you use the contents of the CVS/
directories to set the cvs: attrs correctly.  The thing that makes it
tricky is that if some of those files have been modified already
locally (and you can detect this from timestamps), then you can't
create a monotone revision that exactly mirrors a snapshot of the
upstream CVS repo, because you don't _know_ what all the files in the
CVS repo look like, you just know what they look like plus some local
modifications.  The solution is to have some way to stick a cvs: attr
on a file that means "this is _like_ <such-and-such cvs rev>, but
different", and then take that into account when calculating sync
info.  Current IIRC cvssync does this by, effectively, putting a
cvs:revision attr on that claims the file _is_ in sync, but then
putting a cvs:sha attr on that that does _not_ match the existing
file, and then later noticing this weird state and treating it
appropriately.  But we decided that a better way to do that would be
to just have some magic in the cvs:revision field, like "revision=1.1"
vs. "revision=1.1+" to indicate the special case.

-- Nathaniel

-- 
"If you can explain how you do something, then you're very very bad at it."
  -- John Hopfield