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

Re: Recommended Subversion Repository Structure

From: Blair Zajac <blair_at_orcaware.com>
Date: 2006-03-24 17:46:43 CET

On Mar 24, 2006, at 8:33 AM, Gale, David wrote:

> Jay Lessik wrote:
>> I'm new to subversion so forgive me if this question
>> is newbie-ish...
>>
>> I know that project repository structure has been
>> discussed on this list and I've read a lot of the
>> posts, but I wasn't able to find a clear answer to the
>> question of which of the following is better?
>>
>> repository/
>> projectA/
>> trunk/
>> branches/
>> tags/
>> projectB/
>> trunk/
>> branches/
>> tags/
>>
>> OR...
>>
>> repository/
>> trunk/
>> projectA/
>> projectB/
>> branches/
>> projectA/
>> projectB/
>> tags/
>> projectA/
>> projectB/
>>
>> The documentation recommends the first structure as do
>> a lot of other sites and people on this list, but this
>> post
>> (http://svn.haxx.se/users/archive-2005-04/1870.shtml)
>> seems to recommend the second structure and lists some
>> good reasons... Would using the second structure
>> cause problems down the road? I don't want to have to
>> reorganize my repository later when I find out I can't
>> do something or something isn't working properly...
>
> They both work, and both allow (roughly) the same reorganization
> possibilities. The thing to be aware of is that, at least until SVN
> supports true renames, reorganizing your repository is painful--anyone
> who has checked out your code may need to delete their working copies
> and re-checkout, especially if they've been working on a moved file.

They won't have to delete their working copies, they can just use svn
switch to point to the new location.

And I don't believe that supporting true renames will make the re-org
any less or more painful, the developers will still need to switch
their working copies over to the new location.

>
> Personally, I'd examine how closely ProjectA and ProjectB are related;
> if they're not at all, consider setting up two repositories (one for
> each). Short of that, I'd tend to go with the second repository model
> (repos/{trunk/tags/branches}/{project...}), as that's clearer to me,
> though the distinction is small; one of the few instances where it'll
> come up is checkouts:
>
> svn co <repos>/trunk/projA
> ...creates a directory named "projA", whereas
> svn co <repos>/projA/trunk
> ...creates a directory named "trunk", which is hardly helpful.
> Especially since you can then switch it to a branch directory, and
> confuse everyone. Of course, you can get around this by always
> explicitly setting a directory name, but why bother?

That's just a naming issue. One many of the projects I work on, we
have per-user branches and a trunk where users merge their work
into. So you end up having a directory containing working copies
named like this:

$ ls
projecta-branch
projecta-trunk
projectb-branch
projectb-trunk

Here it's implied that the branch is my per-user branch.

So you'll have to specify the directory to check out into anyway.

So I still recommend that you have the project/{trunk,tags,branches}
structure.

Regards,
Blair

-- 
Blair Zajac, Ph.D.
<blair@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Mar 24 17:48:21 2006

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.