[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 
time soon.

> 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:

	fooproject/
		doc/
		test/
		src/					<-- This is exported
		...

	barproject/
		docs/
		src/
		libraries/
			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
> 	log."

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.

-- 
### SER   
### Deutsch|Esperanto|Francaise|Linux|XML|Java|Ruby|Aikido
### 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
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20040303/6cedcb98/attachment.pgp 


More information about the darcs-users mailing list