[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] New cvssync.attrs branch
Re: [Monotone-devel] New cvssync.attrs branch
Tue, 20 Mar 2007 20:27:17 +1100
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
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
Is your handling of :revision etc. robust against people who swap
files around? I.e.:
mtn rev 1: foo.c cvs:revision=1.1
<rename rename, ignoring this cvs gunk>
mtn rev 2: foo.c cvs:revision=1.3
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
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.
- Re: [Monotone-devel] New cvssync.attrs branch, (continued)
- Re: [Monotone-devel] New cvssync.attrs branch,
William Uther <=