[darcs-users] Per-directory version control
droundy at abridgegame.org
Thu Mar 4 12:26:43 UTC 2004
On Tue, Mar 02, 2004 at 08:35:53AM -0500, Sean E. Russell wrote:
> This is a practical example of a topic which has come up numerous times in
> this mailing list, and which, I feel, has never been adequately addressed.
> So, my question is:
> What is the recommended process for expediting cross-pollination of
> subdirectories in darcs repositories?
Basically there are two ways of doing this (one of which is Kenneth's
suggestion), both of which would be far easier if they had some help from
within darcs. But first let me go over the limitations. Because darcs is
both changeset-based and distributed, you cannot export a subdirectory if
there are changesets which modify both its contents and other parts of the
repo (unless you want to export the subdirectory without the result of
those changesets, and they commute...). In short, changesets cannot cross
repository boundaries, because one can never know if both repositories will
exist--this is because darcs is distributed. So the question becomes one
of how one can avoid having changesets cross these boundaries.
The "safest" solution is that suggested by Kenneth, which is to have a
separate subrepository residing within the mother repository. This is safe
because files in that repo aren't in the mother repo, so you can't
accidentally record a changeset that modifies both files inside the
directory and outside the directory. Similarly, you can't accidentally
move files from outside into the subdirectory (which would cause trouble).
The downside of this method is that you have one more repository to deal
with. It would be nice (when using this method) to have darcs (as Kenneth
suggested) keep track of what subrepos exist, so it can deal with them when
running get, push, pull, etc. This support wouldn't be too hard to add,
but I wouldn't want to add it (and the extra complexity) unless I'm pretty
sure both that this feature will be used, and that it *should* be used.
The other (and currently more dangerous) solution is to *not* have a
separate repository for the subdirectory. Instead you are just very
careful never to record a patch that modifies both the subdirectory and
files outside the subdirectory. The another repo can pull just the patches
to the subdirectory (which are perhaps marked with a unique token in their
patch name, so you can "darcs pull --patch-name=ONLYSUBDIR"). This is
dangerous, because any patch that spans the repo boundary will break the
system, which suggests a feature in darcs to prevent recording such a
This method is *appealing* because it is both more flexible than the
sub-repository approach (you could, for example, export two directories
together, if you wanted), and in some ways simpler--you only have a single
repository for each mother project. Also, you can in principle change your
mind about a directory that you originally intended to export without
changing your repository in any way.
There are a couple of ways I can imagine adding nice support for
"subprojects" of the second kind. Unfortunately, they would pretty much
all have to start when the files or directories to be shared are created.
Of course, you could remove and add them to break history to do this later.
Anyhow, each changeset affecting the subproject would have to be annotated
in some way (perhaps in the name), and darcs could be told via a prefs
option that patches containing in their name ID can only modify files or
directories which were created by patches with ID in their name.
Similarly, patches without ID in their name cannot modify files or
directories having ID in their name. This would be a bit of a pain to
implement, though (even more than the subrepository stuff), so I definitely
wouldn't want to do it unless I were sure both that it were a good idea,
and that it would actually be used.
Mostly why I haven't implemented either of the above, is because it is hard
for me to imagine many situations where sharing subdirectories is really a
good idea. Obviously I shouldn't force darcs users to write their software
using only what *I* consider good design practices, but it also doesn't
make much sense for me to add complexity to darcs just to support features
that I don't think anyone should ever used.
In many (most?) cases where a subdirectory is shared, the subdirectory is
really a library, and in such cases I don't think that shared sources is
the way to go. Libraries should be packaged separately from the programs
that used them.
The examples you gave don't fall in the category of libaries being included
in the sources programs that use them exactly, but rather in small projects
being subsumed (or consumed?) by larger projects, which is a bit more
reasonable. I guess this can really only (justifiably?) happen for things
like the kernel or compilers (other than C compilers), which can't work
with binary libraries--the examples you gave. Neither of these seems
common enough or useful enough to justify any significant changes to darcs.
It seems like if the compiler includes your library source code it really
ought to include your test suite, etc, and if it just included your entire
project, there wouldn't be a problem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20040304/9f058266/attachment.pgp
More information about the darcs-users