subversion usage (was: Re: gEDA-user: Symbol submission)

[Andy Peters <devel@xxxxxxxxx>]

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@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user