[darcs-users] Repo Knowledge Management
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
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
- 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
* 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
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.
More information about the darcs-users