[darcs-users] Archives/meta-repositories - a proposal

[Tuomo Valkonen]

I have never really used darcs, but recently in a discussion concerning
version control systems on an IRC channel darcs was mentioned, and I
checked it out. It looks interesting and I really like how conveniently
"micro-branches" can be created with it. However, I'd like there to be
a way to organise bigger "real" branches and multiple projects into a
single "meta-repository" or archive. The problem with simply arranging
the repositories in a directory is that as the repositories are passed
between file systems and computers, the hard links will break and the
repository directory becomes bloated and unsuitable for mirroring in
a possibly small web space. Additionally it would be nice if tagging
and branching were almost the same thing.

So, I started thinking of a way to implement such meta-repositories, 
and I think it could be conveniently done with just two extra commands
and very little changes to rest of darcs. The commands would be:

	darcs initarch archive-dir
	darcs archive src-repo archive-dir/dst-repo

The idea is that archive-dir contains a directory, _darcs_meta/patches  
that contains the patches for all the repositories in the archive (or 
meta-repository). The 'archive' command would then check that the source
repository has no unrecord changes (in case of a "working copy" repository
as opposed to an archived repository), see what patches this repository 
needs, possibly fetch them from somewhere else, and copy the missing patches
in archive-dir/_darcs_meta/patches. Then it would copy src-repo/_darcs
as archive-dir/dst-repo/_darcs. (There's no need for the "work files" here.)
What it would do with the patches there depends on whether --partial 
already does that or if there's any incentive in making get to only fetch
a list of required patches and their locations. If such a feature seems
useless, symbolic or hard links to the patches in _darcs_meta/patches 
would be created. Otherwise only a list of the required patches would be
created. 

In case of an archived repository, the 'get' command would then rebuild
the work files from _darcs/current. If patch listing in the archived
repository is implemented as links, no other changes should be necessary
(depending on darcs would currently handle symlinks if those are used). 
If the patches are listed in a file, well, the changes depend on what
--partial is supposed to do (it didn't seem to do anything when I tried).

Pushing new patches to an archived repository would be handled similarly 
to the archive command.


Additionally, to implement tagging with the archive command, a --tag flag
could be added that would cause darcs to create an unpushable lightweight
repository without even the _darcs/current data, so that tagging and 
branching could be unified (I prefer it this way) without wasting too disk
space. (As far as I know, it is possible to reconstruct current from patches.
It may be slow, but doesn't matter with tags unlike with branches.)


I think this rather simple extension to darcs would be very convenient for
creating bigger branches that are supposed to be mirrored and seen by people
and even as a replacement for tags. For example,

	darcs initarch /share/darcs
	mkdir project && cd project
	darcs inittree
	... Work on the project and record smaller changes ...
	darcs archive . /share/darcs/project-devel
	... Work on a new feature recoding smaller changes ...
	darcs push (in /share/darcs/project-devel)

	... time for a release (automated) ...

	darcs archive --tag /share/darcs/project-devel \
		/share/darcs/project-devel-`date +%Y%m%d`
	
	... getting stable, let's branch it ...

	darcs get /share/darcs/project-devel
	cd project-devel
	... do some final preparations ...
	darcs archive . /share/darcs/project-stable


...


As an aside to the main topic of this post, one thing I'm not so sure of is
if log messages are a good way to identify patches. Couldn't the (cryptic)
file names of the patches be used alternatively, and allow for conflicting
log messages?

-- 
Tuomo