[darcs-users] How to "simulate" CVS vendor branches?

David Roundy droundy at jdj5.mit.edu
Mon Oct 27 12:12:49 UTC 2003


(Apologies for replying to myself, but I've thought about this, and now
disagree with some of the things that I said.)

On Sun, Oct 26, 2003 at 06:53:17AM -0500, David Roundy wrote:
> > How would I set this up? Do I use several distinct darcs
> > repositories and push/pull individual patches around with
> > some tag trickery?
> 
> This is what I would suggest.  Each library and tool should have its own
> repository.  Where things get ugly is when you make changes in the project
> repo (using "project repo" to describe a repo containing libraries plus
> local files).  Each patch you record must only contain changes to either
> local files or files from a single library.  Otherwise, the patch won't be
> able to be pulled into the library repository without pulling in the other
> files it modifies.

There are even more problems this.  If you want to have a library
repository, you expect the library files to reside in the root of that
repository (or at least I would).  This will cause problems, however, with
pulling that library repo into any other repository.  If there is any
filename conflict, you will have major difficulties (e.g. if both library
and "project" contain a file named ./Makefile).

One solution would be to have libraries always put just one directory in
the root of the repository, and keep all their files in that directory.
Unfortunately, this is a very ugly solution (IMO), and also the decision
would need to be made when you first create the repository.  You couldn't
later move the files into a subdirectory, since when you pull into the
project directory you'd first get a conflict, and then end up moving both
Makefiles (which are now conflicted) into the subdirectory.  Yuck.

One idea I had (and I'm not sure if it's either feasible or worthwhile) is
to give the root directory of each project a name (other than "./").  This
is similar to the "project-name" idea, but it is a root directory name.  It
may be able to do this in a backwards-compatible way, and it would
definitely deal with the problem of conflicting files in totally unrelated
projects, and may even deal with the "project-name" issue.

The idea would be to have a sort of virtual patch in each repository (in
effect, the first patch to be applied), which renames the root directory to
".".  Being a virtual patch (which is a new concept), the root directory
rename patch would never be pulled from one repo to another, and when you
pull patches from a repo with a different root directory, they would have
to be commutted by the virtual patch.  So if I create two repos, each with
one patch in them:

lib:
(virtual) mkdir "lib" (note: this is not "./lib")
(virtual) mv "lib" "."
addfile "./Makefile"

proj:
(virtual) mkdir "proj"
(virtual) mv "proj" "."
addfile "./Makefile"

Then if I pull from lib to proj, I'd get:

proj:
(virtual) mkdir "proj"
(virtual) mkdir "lib"
(virtual) mv "proj" "."
addfile "./Makefile"
addfile "lib/Makefile" (note the lack of "./" here)

There are some issues here, like the fact that I had to pull the virtual
mkdir "lib" into proj, and it's not clear how the virtual mkdir "lib" can
be removed from proj.

This idea needs more thought.

> > Or is this all really just _one_ repository with even more
> > sophisticated tag trickery?
> 
> This is the CVS way of doing things, but I don't approve of it.  You
> presumably want someone else to be able to use your libraries without
> grabbing the rest of your projects.

As I think about it, in some cases this may sometimes be the correct thing
to do.  Especially if the projects in question are very closely linked.  In
the case of general-purpose libraries, however, I still believe each should
be in its own repo.
-- 
David Roundy
http://www.abridgegame.org




More information about the darcs-users mailing list