general source control strategy for many projects and many developers

[Ryan Jarvis <ry...@muzzylane.com>]

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.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: general source control strategy for many projects and many developers

[Rush Manbert <ru...@manbert.com>]

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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: general source control strategy for many projects and many developers

[Ryan Schmidt <su...@ryandesign.com>]

On Jan 3, 2008, at 09:20, Ryan Jarvis wrote:

> 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.

You mean: in the repository. These would not be directories on the  
server's hard disk.

> 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.

Note that performance will be better if the user issues the "commit"  
or "update" command only on the subdirectory they're actually working  
on. If the user knows she has not modified any files in any other  
directories, it is inefficient to still make Subversion look for  
changes in those directories.

> 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? [snip]

I believe the non-recursive checkout feature might meet your needs:

svn co -N url://to/projects
cd projects
svn up calc
svn up spreadsheet

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org