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

RE: Didn't create trunk/branches/tags, now what?

From: Engebakken Geir <geir.engebakken_at_edb.com>
Date: Fri, 8 Jan 2010 12:57:24 +0100

The fact that restructuring a repository generally is of no importance is something that I am unsure of, but maybe not in this simple case.

If you at some time for example want to split a repository by doing a dump and later load parts of it into several repositories, you will get into problems with svndumpfilter if you have moved things around too much, since svndumpfilter can't handle copies from a path that is not included in the dumpfilter.

The same will also create problems if you want to extract parts of a repos and place it in another.

Geir

-----Original Message-----
From: David Weintraub [mailto:qazwart_at_gmail.com]
Sent: 7. januar 2010 18:48
To: Eric
Cc: users_at_subversion.apache.org
Subject: Re: Didn't create trunk/branches/tags, now what?

 There is absolutely no reason why you can't restructure your
repository. The only thing you have to be careful about is people who
currently use your repository layout. If you move the roots of
projects, people who have a current checkout will have problems trying
to do a commit.

How many projects do you currently have?

Remember that the standard repository layout is ONLY a suggestion.
There is nothing magical about the naming or structure. The only
advantage is that everybody knows it and it is simple to understand.

How is your directory structure laid out now?

Is it something like this:

http://host/svn/proj1/...
http://host/svn/proj2/...
http://host/svn/proj3/...

If that's the case,  You could create two directories at the project
level called TAGS and BRANCHES. By making these in all caps, it would
be easy to distinguish them from other projects.

This way, you don't have to restructure your current projects. Then
when you create a tag, you could do something like this:

cp http://host/svn/proj1 http://host/svn/TAGS/REL-1.0

The only problem is that the checkout would be
http://host/svn/TAGS/REL-1.0/proj1.

If you have a single project in your repository and it's at the root
of your repository, adding a tags and branches directory will cause
problems because the default checkout will also checkout these two
directories. In that case, you'll need to restructure your repository
anyway.

Basically, you have to choices: Restructure your repository to a
standard layout (better in the long term anyway), but you have to work
with people who have a modified checkout from your repository. You can
tell everyone to check in their work, you do the restructuring
(shouldn't take more than a few minutes), and then have your users do
a "svn switch" to the new layout. (Having everyone do a commit before
you do a restructuring is not 100% necessary. It is possible to do a
switch with modified files, but the results can sometimes be messy).

The other choice is to do a non-standard layout where you simply add a
TAGS and BRANCHES directory. These must be added at the project level
and not the checkout root level. If you have multiple projects, this
isn't a bad thing to do. If you have a sinlge project and people
checkout from the root of your repository, you will have problems.

On Wed, Jan 6, 2010 at 9:46 PM, Eric <spamsink_at_internetsmallfry.com> wrote:
>
> Well, it seems that when I created my Subversion repository, I neglected to
> create the trunk / branches / tags as recommended (yeah, I know...).
>
> Hasn't been a problem up to now but now we're going to want to start using
> tags.
>
> So, any reason I can't just create the trunk / branches / tags directories
> in my sandbox, and then (using TortoiseSVN on WinXP) do an "svn move" of my
> whole directory tree into the trunk directory, then to an "svn commit" of
> the whole thing?
>
>

--
David Weintraub
qazwart_at_gmail.com
Received on 2010-01-08 12:59:45 CET

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.