[darcs-users] Per-directory version control

[Kenneth Knowles]

> ... sort of, although it seems like a complex solution to work around what are 
> fundamentally limitations in the architecture.  This leads to making the user 
> interface more complex simply to keep the back-end simple, which always seems 
> like a bad idea to me :-)

I agree, if it were implementation we are speaking of, but since we are talking
more of principles, it is very relevant to the end user, who is the one juggling
the available principles to get the behavior they want.

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 this.
Though it is merely semantics, I can imagine for a moment that foo is just a
normal subdirectory of foo-project.  Then what you would want to do might be

$ cd /path/to/bar-language
$ darcs pull --only-files='foo'  /path/to/foo-project

To only apply the portions of patches that belong to the foo subdirectory.
But this way of only updating certain files, or certain directories is not
exactly the whole-tree-changeset way of source control, and I certainly don't
know what the state of the bar-language _darcs/inventorypatch should be.  I wish
someone more versed that me would step in here.... In any event I think that
having 'foo' is the Right Thing To Do, given this model of source control.

I'm trying to de-emphasize DARCS, because arch has the same issue, and solves it
(if I recall correctly) the same way.

> > $ darcs pull
> > [pulls all of foo-project]
> > Would you like to pull subproject foo?  y
> 
> This is sort of nice, actually, although I'd guess that the cases where 
> subprojects are optional to the project would be few.

The command could certainly default to non-optional, but since pull is already
an interactive command, its not much overhead in the UI.

> Indeed, I still have a 
> problem with the mental image that foo is a separate project.  For me, it 
> isn't.  It is the sourcecode to the project -- it IS the project.

Oh wait!  Do you mean to say that "foo-project" contains only "foo" ?  If so,
then my suggested solution would be this:

$ cd ~/projects/foo
$ darcs inittree; darcs add ...
$ cd ~/projects/bar-language
$ darcs inittree; darcs add ...
$ ln -s ~/projects/foo foo
$ darcs subproject foo

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

	"Any set of sources which varies independently should have its own patch
	log."

So in the original 3-project example, since 'foo' varies independently of
'bar-language', it must have its own patch log, which means it must be an
independent project.

The subproject command of course doesn't exist... I really want others' opinions
on the likelihood of integrating it before I do anything towards it.  I don't
want to advocate command-set inflation but I find your case compelling.

Kenn