Rather than simply checking out svn://myserver/software/trunk as a
whole, check it out non-recursively, then individually check out the
sub-folders you want on that client.
I believe "svn update" will then only update them (minor testing here
appears to confirm this).
For everything except groupG and projectE it would look like this. The
"-N" is the important bit.
svn checkout -N svn://myserver/software/trunk config1
cd config1
svn checkout svn://myserver/software/trunk/projectA
svn checkout svn://myserver/software/trunk/projectB
svn checkout -N svn://myserver/software/trunk/groupC
cd groupC
svn checkout svn://myserver/software/trunk/groupC/projectD
svn checkout svn://myserver/software/trunk/groupC/projectF
"svn update" from the root dir of all of this will only update the
checked out trees.
This does mean that if someone adds in "projectF2" to "groupC" you won't
get it automatically, but given your requirement of "different
machines/developers need different code" that's presumably desired.
If developers find themselves checking out a whole new tree often then
dropping the above in a script may be useful, also possibly storing the
scripts elsewhere in subversion under suitable names so anyone can check
out a particular configuration.
Rob
-----Original Message-----
From: Gavin Lambert [mailto:gavinl@compacsort.com]
Sent: 04 November 2005 05:35
To: users@subversion.tigris.org
Subject: Directory cloaking
I was just wondering if there was any way to (ONLY at the client level,
not on the server) "cloak" a particular folder in a repository, so that
it is neither retrieved by an Update nor committed by a Commit. In
fact, it should behave exactly as if the directory doesn't exist at all
(except that it won't commit a delete for the folder).
It's important that it be a client level thing because I've got a
situation where a single username is used on two different systems --
one which should retrieve a subfolder and one which shouldn't.
To explain a little more, think of this structure:
- repository URL: svn://myserver/software/trunk
- projectA
- somestuff
- projectB
- somestuff
- groupC
- projectD
- projectE
- projectF
- groupG
- projectH
- projectI
On one machine, a developer needs everything except "groupG". On
another machine, they need everything except "groupG" and "projectE".
Other developers have different requirements.
Sure, they could just get everything anyway (which is what they're doing
at the moment). But some of these folders can be quite large (and
busy), and it seems silly & time-consuming to force people to get stuff
they don't need.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 4 08:52:52 2005