eof-drafts — This is a mailing list for draft Free For Comments

[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

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

[<em...@nu...>]

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.

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.

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

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

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.

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.

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

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

Everything Over Freenet Project
==========================
Free For Comment: 	#1
Title: 			Free Concurrent Versions System
Description: 		A clone of internet CVS designed to run via the freenet
			network.
Proposed Version: 	1.0
Time for Comments: 	2 weeks

==========================

Introduction
==========

The aim of this specification is to produce a clone of the internet 
Concurrent Versions System suitable for use via the Freenet datasharing 
network. The system allows anonymous submission of patches to a source code 
tree via freenet.

Basic Concept
============

FCVS requires one person to be a central coordinator of the source tree. This 
person, running the software in coordinator mode, recieves all the patches, 
merges them to the tree, then publishes the tree using a DBR(Date based 
redirect). Known developers creates a DBR SSK keypair, then send their public 
key to the repository coordinator. The repository coordinator adds this 
public key to the software running in coordinator mode. The software will now 
poll each developer's SSK for the patches he has sent since the last check. 
The repository coordinator would initiate this poll. The coordinator would 
then look at each patch he has recieved, then decide whether to merge that 
patch to his source tree. Once all patches have been merged or rejected, the 
coordinator would then use a command in the FCVS software to publish the 
repository for the next DBR period. The DBR update would consist of the 
orginal versions of the files plus all patch revisions. 

Details
======

File naming structure:

Repository:
SSK@pubkey/repositoryname/src/foo.c <- Current version of this file
SSK@pubkey/repositoryname/src/foo.c.orig <- Original file, followed by all 
diffs of later versions - in gzip format

Repository information:
SSK@pubkey/repositoryname/info

Repository information format:
Line 1: Repository name
Line 2-3: Coordinator Contact instructions
Line 4: Current update

Source code file format:
(The source code files are compressed using gzip)
Line 1: Last update date of file
Line 2: Date file was added
Line 3: Comments on latest update
Line 4: null
Line 5: start of source code file

Developer SSK patches:
SSK@developer'spubkey/repositoryname/src/foo.c.num <- num is the number 
increment of the update to that file for that DBR period - counting from 0.

Conclusion
=========

This standard is not yet complete, it requires the comments and suggestions 
from other interested parties. The time period for these comments is 2 weeks 
from date of posting to eof...@li.... Please reply only 
in this thread for comments relating to this draft FFC. At the end of 2 weeks 
the author of this FFC will collate all comments relating to issues of this 
standard, then write the final draft. This final draft will then be voted on 
during a time period of one week, with a majority needed to ratify it as a 
standard. Thank you,

David Findlay