[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

CVS modules functionality -- any movement?

From: Steve Seremeth <subversion_at_seremeth.com>
Date: 2005-03-08 22:18:41 CET

Hello -

I looked through a _lot_ of old threads re: CVS "modules" functionality
and it seems that many folks are looking for the same functionality we
are. We have a repository of about 11,000 files totalling a little over
1 GB of data. In the trunk we have 143 top level directories. Our
application is multi-tiered so we have the usual front end components,
mid-tier components, and backend components. The developers are looking
for a way to checkout a subset of the trunk/branch directories,
depending on the part of the system they are working on -- and
immediately this reminded me of the CVS "modules" feature, where you
assigned an alias to any number of modules in your repository and you
could checkout/add/update/etc. against the alias. The caveat is that
there are, of course, some shared libraries between the various tiers in
the application.

I looked into using svn:externals for this and thought the best way to
implement the same functionality would be to create something like this:

/trunk
    /frontend_component1
    /frontend_component2
    /frontend_component3
    /midtier_component1
    /midtier_component2
    /midtier_component3
    /backend_component1
    /backend_component2
    /backend_component3
/aliases
    /frontend
       svn:externals
frontend_component1=http://www.myrepos.com/svn/trunk/frontend_component1
       svn:externals
frontend_component2=http://www.myrepos.com/svn/trunk/frontend_component2
       svn:externals
frontend_component3=http://www.myrepos.com/svn/trunk/frontend_component3
    ...

However, as soon as you need to branch, you have to repoint your
externals on the branch to the branch instead of the trunk. This
becomes a bit of a management headache. Other folks have suggested
referential paths would be the way to implement the solution, and
perhaps that's right. One semantic that would need to be considered
might be in adding new directories to the working copy. They would have
to be committed on the trunk (or branch) and then added to the "module"
or "alias" after, and the working copy would either have to know that
the alias is just a fraction of the real trunk or the developer would
have to checkout the trunk and then add the directory and add it to the
module/alias. The latter is obviously not very desirable, but if that
was the workaround for now, then so be it.

The developer described the desired behavior to me actually as the
reverse of the "modules" behavior. "Let me choose to ignore certain
directories in the repository, and give me everything else." Either way
you have to maintain lists (the files/dirs you want or the files/dirs
you don't want), and personally I think it's cleaner to define the
directories that make up something than the reverse.

One reason we don't just checkout the directories individually is
because, for example, in TortoiseSVN (most of our developers are on
Windows machines), updating on many directories _instead_ of the one
parent directory is hurrendously painful (major memory hog and
unbelievably time consuming).

Some past threads on the issue (some of which are very thorough):

http://svn.haxx.se/users/archive-2004-03/0797.shtml
 continued here: http://svn.haxx.se/users/archive-2004-03/0835.shtml
http://svn.haxx.se/dev/archive-2004-12/0906.shtml
http://svn.haxx.se/users/archive-2004-07/1732.shtml

I get the sense that there are many folks wanting this feature --
clearly it's not as important as locking, but is it even on anyone's
radar? Consider this a "me too, me too" type e-mail to add our voice to
the fray.

Thanks very much,

Steve

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 8 22:21:30 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.