[darcs-users] Per-directory version control
Sean E. Russell
ser at germane-software.com
Wed Mar 3 18:17:04 UTC 2004
On Wednesday 03 March 2004 12:37, Kenneth Knowles wrote:
> It is my instinct that foo is a separate project, since two projects
> depend on foo, but not each other, and so my examples have stemmed from
Well, it isn't, at least not in my case. In my case, foo-project really is
the project, but bar-project just imports the sources from the foo-project
(ignoring the unit tests, documentation, design and development docs, todo
lists, etcetera). So, foo is the sourcecode directory of the foo-project,
and foo-project is entirely useless without the foo subdirectory. However,
bar-project only cares about the sourcecode.
This really is not uncommon in open source projects. One project provides
some infrastructure, and other projects provide add-ons to that
infrastructure. Sometimes, the add-ons become a "standard" feature of the
infrastructure, so the infrastructure project imports some sourcetree from
the add-on project. However, the add-on project continues to maintain its
own development tree, which may have a different directory structure than
what the infrastructure project imports.
Furthermore, the add-ons often have a different development cycle than the
infrastructure, so people who are keen on having up-to-date sources for the
add-ons may pull distributions and upgrade the add-ons separately.
A good example of this is the Linux kernel. ALSA, DRI, and numerous other
modules are included in the main Linux kernel sourcetree; however, the
projects still maintain their own web site, distribution mechanism, and more
current branches. If you're particularly interested in some DRI feature that
hasn't made it into the kernel yet, you pull the DRI sources separately and
patch your kernel. They're completely different source trees.
This sort of thing also happens in Python and Ruby, and if it were easy, it
might also happen in darcs ;-)
> I'm trying to de-emphasize DARCS, because arch has the same issue, and
> solves it (if I recall correctly) the same way.
Well, that may be the right solution, then, especially if it is doable with
the current darcs architecture, which is unlikely to change radically any
> Oh wait! Do you mean to say that "foo-project" contains only "foo" ? If
> so, then my suggested solution would be this:
No, no... the example from my first email was this:
src/ <-- This is exported
fooprojcet/ <-- This is "fooproject/src"
> The only reason to have 3 projects was because I thought both bar-language
> and foo-project had additional independent sources. I think the rule of
> thumb that I'm driving at - and I think it applies in principle, not just
> implementation - is
Well, that could happen, too. Heck, it might even be common. But in my case,
I'm exlicitly wanting to export a subdirectory to another repository, and
have an easy way of keeping them in sync without having to re-apply patches
and type in log messages.
> "Any set of sources which varies independently should have its own patch
But, in my case, it wouldn't. I'm the only person who maintains src/*.
However, this src/* is a "standard" feature of another project that includes
it. In fact, the whole problem is that that subdirectory *doesn't* change
independantly, yet it has to be maintained as if it *did* change
independantly. By "change independantly", I mean that different edits are
made to the different trees, not that they're always in sync. The imported
project may be updated less often than the exporting project, but,
ultimately, the changes are identical, and should have identical change logs.
### http://www.germane-software.com/~ser jabber.com:ser ICQ:83578737
### GPG: http://www.germane-software.com/~ser/Security/ser_public.gpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20040303/6cedcb98/attachment.pgp
More information about the darcs-users