[darcs-users] Repo Knowledge Management

Max Battcher me at worldmaker.net
Tue Mar 22 23:27:00 UTC 2005


I've been thinking some on this topic and the recent discussion on the 
annotate format, as well as reading one person's reasons for disliking 
darcs' repo-branch equivalence, has made me think that perhaps others 
might be interested in my thoughts.  I apologize ahead of time for a 
long post, but I find it interesting.

Basically, there are several topics that I think are all inter-related: 
version management (requests for automatic revision numbers in darcs) 
and branch management.  (Together I refer to both of these and other 
related issues as "Repo Knowledge Management" (RKM).)  What is 
intriquing about these issues, and why they continue to come up in 
discussions about darcs, is that these are largely handled by a 
traditional source control systems like CVS or SVN but darcs doesn't yet 
touch.

I believe that darcs is actually correct in not touching them and that 
RKM is precisely where good darcs hooks could benefit the most.  The 
reason for this is due to darcs' distributed nature and simplicity, 
which lead to actually the possibility of multiple useful RKM systems 
based on both tastes and needs.

The two main questions that categorize these needs are "How do I keep 
track of revisions?" and "How do I keep track of branches?".

For the smallest projects (such as my own currently) all of the work can 
be done by the human mind.  I have no problem keeping track of branches 
and versions when there are few and I'm the only developer.  Revisions I 
can tag manually at important milestones.  Branches I can keep track of 
because they are relatively few.  In fact, most of my need for branches 
is in the form of temporary branches for working with a previous tag.

For larger projects developers want some sort of automatic revisioning 
(I've read the several requests for a CVS $Id$-like functionality) and 
some sort of branch manager.  I think that ultimately these become 
"discussion" / "team communication" issues and that there are several 
ways to solve these.  Here are a few of the ideas I've had or seen:

* Email Discussion List - This is obviously the system already in use by 
darcs itself.  That's also why it makes the best starting point to 
describe where I see things can go.  The things to make this a "fuller" 
RKM system would mostly be in the realm of integration with your MUA:

- Branch management: Why not use an email list as the primary patch 
distribution system?  Instead of just failed patches bouncing to the 
list, all patches would hit the darcs-devel list and users (with 
appropriate mail client plug-ins) could browse through their email and 
push patches from their mailbox directly to their own copy of the repo 
from their MUA.  You would want some way to connect your mail folder to 
one or several local branches.  You might even like to see patches 
highlighted a different color from discussions.  You would also probably 
like highlighting for those patches that were accepted.  You would also 
want some sort of feedback for which patches were accepted officially to 
stable (or other branch).  The maintainer could send an automated and 
signed automatic "patch x accepted to stable" message that the MUA could 
eat and use for highlighting purposes (or it could require something 
like a majority vote for a democratic project).  You would also probably 
want the MUA plugin to poll darcs changes and produce a list of patches 
to send.

- Version management: Similarly, what about tag marking in a mail 
client?  You would probably want these only accepted from the 
maintainer.  Automatic revision numbers could be defined relative (with 
darcs all automated revisions have to be relative) to the mailing list 
and anyone with the appropriate MUA plug-in could back-track to it. 
(Example: darcs-devel at darcs.net/stable revision 29)  The key would be 
assuming that the mailing-list adequately mails things in the correct 
order (and which you have both patch dates and list dates to back up), 
then you use a technique like the one mentioned in the annotate thread 
where each repo-affecting action gets a new number.

* Forum - What about a *BB in which patches are attached to posts?  It 
would be quite similar to the email list.  You could modify an existing 
*BB system to provide all of the highlighting and functionality I 
mentioned above.  For this you would want some sort of automatic patch 
installer when downloading, say, something.darcs patch files.  You'd 
want it smart enough to recognize a particular forum URL (probably 
embedded in the patch header) and associate it with local branches.

* Bug Tracker - Similar to the forum...  why not post patches directly 
to RT/Bugzilla/whatever and keep track of the RKM in a modified one of 
these?

* Project Manager - Similar plug-in for a Project Tracking application 
like MS Project?

The list could go on from there.  I see immediately a project for 
someone to create a "web format" patch with a "fromURL" and simple 
".darcs" launcher for applying those patches to known local branches.  I 
could probably mock one up pretty quick in C# with a simple GUI.

(Aside: how do you get a text patch like send produces without having to 
email it?  I can't find how in a brief manual examination.)

Now, with all of that in mind I'm going to dive out into the further 
waters that have been pulling my interest.  What about true distributed 
projects?

The idea I had been thinking about for some time was writing a 
mini-Jabber client that would basically use Jabber as a transport agent 
for darcs.  This would allow me to work in a more "peer to peer" way 
across the internet.  For my own purposes, I don't want to set up a 
server on my laptop, and if I set up a server on my desktop, I can't 
access it through the several firewalls once I'm outside the local 
network.  Not too big of a deal to try to remember to simply manually 
sync when I'm at the local network, I'll admit, but then I started to 
think about some of the repercussions of using Jabber for RKM.

I think for a truly distributed development project you need a more 
peer-to-peer structure, and that it offers an interesting model for 
development.  With a useful RKM interface (for example, "buddy list" of 
fellow developers and a notification of when/what they patch in relation 
to your branch(es)) patches (including version tags) could very well 
travel democratically (although some might see it as anarchic, you would 
assume all of the devs in your buddy list you know and have some idea of 
what their patch choices represent) across a network of developers 
rather than having a single maintainer.  Stable and other branch 
determinations could be made also democratically (both ann at example.com 
and bob at example.org have patch x in Stable; so I guess I should too). 
The biggest issue is trust, which I think gets solved in two ways: the 
developers you trust to put in a "buddy list" and in the case of, say, 
Jabber the server identity authentication (there is only one 
bob at example.com and he is password protected; this could also be done 
with key signing for a further decentralized system).

Anyway, that's a lot of thoughts scattered across a couple of topics.  I 
hope some find my thoughts interesting and/or enlightening.

In recap: decoupled RKM from darcs is good, there are places to build 
cool RKM helper apps for darcs, there are further places to explore with 
distributed source control in decentralized environments.

-- 
--Max Battcher--
http://www.worldmaker.net/




More information about the darcs-users mailing list