| gabriel rosenkoetter on Thu, 27 Sep 2001 21:00:23 +0200 |
|
On Thu, Sep 27, 2001 at 11:25:42AM -0400, Chris Beggy wrote:
> Doesn't the anoncvs host have most of the information it needs
> when it sees the post? You (or some other project member) have
> already written a client to parse the nntp traffic on each of the
> anoncvs hosts. Can the client also do a local cvs commit of the
> patch in the post, rather than some kind of cvs update or remote
> sync?
I've written all that's written, and it's not quite functional just
yet (I actually need to get in touch with Wasabi about this, which
is the reason I'm even reading email at the moment ;^>). It's all
kind of hackery, and involves using both commitinfo and loginfo from
CVS in ways distinctly other than they were intended and using a
channel feed in INND to do kibo-istic stuff (that's where the
patching of the anoncvs repository happens), so it's not something
you want to try using unless you understand all of how CVS's CVSROOT
control files work, how INND works, and a lot about how CVS stores
its repository.
You've misunderstood the mechanism just a touch, but only because I
didn't explain clearly. The posted diff is a diff of the RCS ,v
file. (Yes, this can run into some nastiness in which diff just
loses; there is a planned and soon-to-exist bail-out mechanism for
that situation involving another newsgroup in which anoncvs machines
can request a repost of the whole ,v file, probably tagged with a
unique ID to avoid the wrong repository replacing its ,v file
inappropriately. There'll also have to be some smarts not to apply a
higher sequence number patch to a given file until the repost.)
The post contains not just the diff, but also an md5 checksum both
before and after the commit that just happened and a gpg signature
from the central CVS server. (All for obvious reasons. Even if we do
use SSL-enabled nntp, which INN can only do awkwardly at the moment,
or even construct an SSH tunnel between each of the servers for this
traffic, all of those assurances of non-tampering will have to
remain.)
It's precisely the point that the client can update its local
version without having to do a cvs update or remote sync request,
though it does it just by running regular old patch on the diff in
the post.
What this *doesn't* allow is having more than one CVS server to
which one can send commits but it is *really* easy to add this just
by generalizing the mechanism and having a "commit-from" newsgroup
for each host which every other host watches. This would complicate
sequence numbering (you don't want to apply patches out of order,
and if a commit is performed on one host before that host's tree has
been updated from the remote ones, you want to know that the patches
clash and that a--probably manual--merge needs to be done between
those two repositories and the resulting diffs sent out to everyone...
but this is a pathological situation that only happens when two
people are working on the same block of code and commit at esxactly
the same time: even if they're in the same file but at different
places, chances are good that an intelligently issued diff will
win.)
And that's probably on the way.
Other things that have really been pissing the NetBSD/Wasabi crew
off about CVS include its completely moronic behavior regarding
directories. Which Perry Metzger (W's CEO) and I both agreed
couldn't be that hard to fix (though getting them by Greg A. Woods,
Change Nothing in CVS Nazi could be difficult). So if you're bored
and want to hack CVS to be better without duplicating effort, I'd
be willing to expound on how we think that *should* work. (If not,
I'll probably get to this after I finish classes this semester.)
--
~ g r @ eclipsed.net
Attachment:
pgp3iRxI3R4Yd.pgp
|
|