[darcs-users] Archives/meta-repositories - a proposal
tuomov at modeemi.cs.tut.fi
Wed Mar 3 18:50:50 UTC 2004
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
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
... 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 \
... getting stable, let's branch it ...
darcs get /share/darcs/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
More information about the darcs-users