Ryan Jarvis wrote:
> Hi,
>
> I asked this question on irc but didn't get a definite yes or no. I'm
> looking to determine a particular strategy as my office expands the
> number of projects needed to be under source control.
>
> On the server, I would like to have a bunch of source dirs like "calc",
> "calendar", "spreadsheet" etc. with the trunk, tags and branches
> subfolders underneath.
>
> I would like my end-users to create a project dir called "projects" on
> their local development machines and inside it only checkout the source
> dirs that are currently relevant to them. For example, "calc" and
> "spreadsheet".
>
> Now, the process for my end-users I want to be the same: using
> TortoiseSVN or equivalent, they run the commands 'update' and 'commit'
> on the "projects" dir only, not on any source dir underneath it. During
> the update, I want their projects dir to only pull down the changes to
> the source dirs they have currently checked out. During the commit, I
> want all changes in all their source dirs to be checked in as a single
> revision.
>
> Is this situation possible out of the box? Could it perhaps be
> possible if I wrote some python scripts the my end-user would call
> instead of svn commands directly?
>
> The two approaches I have tried so far do not meet my needs. If I put
> all my source dirs under one folder on the server, end-users end up
> checking out everything when they update. Some source dirs (i.e.
> "calendar") may contain 100+ mb of binaries that I do not wanting tying
> up their bandwidth if those source dirs are not currently relevant to
> them. They could still check out source dirs individually from this
> single folder, but then they can't run an update or commit command from
> their project dir, they have to run them individually on their source
> dirs inside the project dir. The second approach would be to have each
> source dir its own root, but then my users cannot commit changes to
> multiple source dirs as a single revision. Currently, each revision
> increment in our setup corresponds to a single conceptual change (i.e. a
> simultaneous change in both "calc" and "spreadsheet" may constitute a
> Feature) and as we expand I would like to keep it that way.
>
> Any thoughts on this would be greatly appreciated. Thanks.
>
Hi Ryan,
What you want to do is not possible, AFAIK, out of the box. I have
solved a very similar problem (cross platform development with 300Mb of
libraries that are platform-specific and don't need to be checked out
indiscriminately), but it makes for a somewhat complicated repository
structure, and the only way to do checkouts is with scripts that run
command line SVN.
Everything hinges on use of "svn switch". The approach is to make a
placeholder empty directory in your repository for every directory that
you need to check out conditionally. Your first checkout gets the
placeholder directories in the working copy, then you switch each of
them appropriately to the "real" directory from the repository.
In your case, I think you would put all of your "calc", "spreadsheet",
etc. directories under a top level directory in the repository. Let's
call the top level directory "content".
Parallel to the "content" directory, you create a directory called
"placeholders", and in it you create "calc", "spreadsheet", etc.
directories, one per child of "content", and with the same names.
When a user wants to check out, you do the following:
1) Check out the "placeholders" directory into your working copy. This
gives you a top level directory on which you can invoke update, commit,
etc. Your WC now contains a top level directory filled with empty child
directories. The children represent all of the directories that can be
checked out by your end user.
2) For each desired directory ("calc", etc.) use svn switch to point the
working copy directory to the real directory under the repository
"content" directory. This checks out the real stuff and makes it
available for update, etc.
If an end user later decides that she needs to "add" the "foo" directory
to her checkout, she just uses svn switch to point her working copy foo
directory to content/foo in the repository.
Obviously, this requires a lot of script support, for the initial
checkouts, for the "add" operations, for the case where your end user
decides she doesn't need to have "foo" checked out any longer (how do
you cleanly "unswitch" the directory?). You need to support checkouts
from branches and tags and revisions too, so it gets complicated. It
also helps if you use properties to put metadata on the directories of
interest so they can be switched without the scripts knowing what the
switch targets are. I also use the metadata to maintain the official
list of subdirectories that can be checked out.
Best regards,
Rush
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-01-04 01:15:49 CET