[Eof-drafts] Re: [FFC 1] : Free Concurrent Versions System

[David F. <dav...@ya...>]

>I think there needs to be a way for all the developers to get the
>latest patches within the day (or whatever the period is for the DBR).
>Otherwise there's far too much risk of conflicts (more than one
>developer changing the same piece of code).  It shouldn't be up to the
>coordinator to resolve those conflicts, because the coordinator won't
>necessarily understand the changes.

We were thinking about having the whole thing running autonomously, but after 
consultations with thelema we came up with the solution of having the 
coordinator responsible for all that.

>In the case of CVS, you can't commit without having the most
>up-to-date copy.  If other people's patches conflict with the changes
>in your working copy, it's up to you to resolve those conflicts before
>you commit.

Well in this case you would have to wait for the next DBR period to commit. 
And the actual commit would be done by the coordinator.

>In order for this to be possible, you must be able to get the latest
>patches before submitting your own patches.

The problem with that is finding all the patches, and getting them in the 
right order.

>Implementing this is probably as simple as publishing the public keys
>of all the known developers.

Yes well that is part of it.

>Also, wouldn't it be more efficient to use an MSK
>(e.g. SSK@pubkey/repositoryname//src/foo.c) instead of needing a DBR
>for every single file?  Not to mention that then the mapfile can be
>used to get a list of all the source files, which it doesn't appear is
>possible otherwise.

Okay.

>Is there any thought being given to some of CVS' more advanced
>features, like tagging and branching?  Maybe it would be a good idea
>to store the repository in CVS' format, and actually use CVS behind
>the scenes to manage it.

Using CVS itself isn't really possible because we can't change files once 
they are in freenet. Here's another idea:

The coordinator releases the most up to date version of the code at the start 
of the DBR period. Say two hours later developer x updates his CVS. His 
program updates to the coordinator released version, then checks all other 
developer's SSK's for patches to today's version. The developers wouldn't use 
mapfiles, just incrementing patches with a DBR reset that would be say one 
week. To commit a change to a file, you just post a diff to the file from the 
latest version you have. Then when developer y checks out the file he gets 
your diff as well as the day's original. It's not ideal, but it should work.

As for the other stuff like tagging(I don't know what that is) and 
branching(we can do this) I'm sure it could be done quite easily. Do you know 
heaps about CVS? We really need to push this standard and a reference 
implementation out quickly so development of Freenet can move from 
Sourceforge to in-Freenet if the need arises. Thanks, 

David