On Dec 15, 2006, at 3:56 PM, DJ Delorie wrote:
There seems to be a way to deal with just sub directories of a tree,
after you have the whole tree. If you move that subdir to a new
place, it still functions as a svn working copy of that much of the
tree, and you could then delete the rest with no impact on the
repository.
But if you do an update to a specific version (or date) after moving
the subdir, it re-creates the subdir.
Which is as it should be, because you update to the specific state of
the repository as of whatever revision you choose.
But if you update to HEAD, then assuming that subdirectory move was
done properly (and if done from a working copy, committed back to the
repo), the moved subdirectory vanishes from updated working copies.
The thing that svn can't do is check out a tree WITHOUT getting
specific subdirs. For example, getting pcb without the documentation.
I have no idea what the tree looks like, but for argument's sake,
assume it's like:
pcb/src
/docs
/foo
/bar
/whatever
One could certainly do:
$ svn checkout http://svn.pcb.org/svn/pcb ./pcb
and get the whole tree.
One could just as easily do:
$ svn checkout http://svn.pcb.org/svn/pcb/src ./pcbsrc
and get just the sources.
This is a big problem for binutils/gdb/newlib/cygwin because they
share a repository and a lot of common top-level files.
The usual subversion solution to this is to maintain the common, top-
level files as their own projects within the repo (or even in a
different repo), and include them using the svn:externals property.
When using externals, a reasonable use case is to always use tagged
versions of the external-ed modules. By subversion convention, tags
are immutable, and the idea is that you always know which version of
every external you use. If you were to simply use the trunk of each
external-ed module, checking out your project always gives you the
latest version of the submodules. When working on your project's
trunk, that might be OK. But, as noted, a tag is immutable, so if
someone has changed submodule foo's trunk, and someone else checks
out and builds your project's release tag, they may not get what you
think they should get.
(Does that make sense? Simply stated, submodules are projects unto
themselves, with their own trunks, branches and tags.)
Anyways, regarding how binutils/etc are organized: if they wish to
switch to svn, a repo reorganization might be in the future. That,
of course, is up to the people who maintain it.
-a
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
