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

[William Uther]

On 20/03/2007, at 6:45 PM, Nathaniel Smith wrote:

> 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?

I've just used what Christof had there, and I believe that the module  
tag only appears on the root dir.  In particular, mtn_cvs help pull  
returns:

pull [CVS-REPOSITORY CVS-MODULE [CVS-BRANCH]]

My, admittedly weak, understanding of CVS (which is also why I'm  
really not the person you want hacking on this - the whole reason I  
want mtn_cvs going is so I can convert this project I'm on away from  
CVS.  It is just nasty.) is that the modules are the top level  
folders in the repository.  When you import a module it populates the  
root dir in mtn - hence that is where the attrs are.

> > 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?

Yup.  The attributes are only used on 'in-sync' revisions.  Future  
"in-sync" revisions have their attributes updated.  If you did the  
above then you have two options.  You can 'pull' from CVS, in which  
case you'll get more descendents of rev 1 (each with correct attrs  
and a sync cert), or you can 'push' to cvs, in which case CVS will  
get some adds and drops for the renames, and the file contents  
updated, then mtn will get a child of rev2 with the updated  
attributes and a sync cert.

However, while I handle normal renames (part of the code I added/ 
fixed), I don't know about the 'swap rename' case you give above.   
That might cause problems... and it does.  I'm not too worried about  
this case.  You could split it over two revisions and it would work.

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

Yeah.  Pretty much.  I'm using it for sanity checks, but I don't  
think it would catch much corruption not caught by other means.

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

Good idea, but not high on my todo list.

> > 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.

It was what I thought up in the sleep deprived state I was coding in,  
but I'd welcome suggestions for a change.

> > 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.

phht.  Use diff and patch until you get back in touch with the main  
repos.  Sounds like feature creap to me.

This is for people converting from CVS!  How many of them are going  
to suddenly decide to convert to monotone when they're away from  
their repos? (although admittedly the disconnected operation might be  
what drives them to change.)

Anyway, there are other ways to solve the problem temporarily that  
don't require more code in mtn_cvs.  e.g:

Start a new monotone project and check your CVS workspace into it  
(ignoring CVS dirs - as is the default).  Keep your old CVS workspace  
around, but use a monotone workspace while you're disconnected.

Do all the committing you want into monotone.

When you get back to being connected, check the monotone workspace  
out over the top of the CVS workspace so it has both _MTN and CVS  
dirs.  For each rev in turn (and I assume there will not be many),  
update to it in monotone, then check in in CVS.

Remember that you only need to do this once to switch.

> 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.

That part I have no deep issue with, although I'm still not sure it  
is worth the code.  99.99% of people will test mtn_cvs before they  
decide to use it, and they'll have access to the repository.

> 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.

That is just ugly.  And a large amount of hackery for a rare use case.

Even if it was working I'd be tempted to take it out.

Will          :-}