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

Re: repository directories layout

From: Ryan Schmidt <subversion-2007b_at_ryandesign.com>
Date: 2007-05-11 00:08:51 CEST

On May 10, 2007, at 07:50, H.S. wrote:

> Ryan Schmidt wrote:
>> On May 9, 2007, at 22:37, H.S. wrote:
>>> If you can give some other pointers regarding creating the new
>>> repositories (I checked the red book, it talks about the
>>> directory structure but doesn't give an example showing exactly
>>> what to commit while creating the repo), that would be an added
>>> bonus.
>> What else would you like to know? I think you've pretty much
>> covered it here.
> Assume a project is underway and a few, say 3, programmers are
> working on the same set of source code files. (I have used CVS
> before, but only for myself and only in a very basic manner). Just
> to clarify what you explained earlier, they do:
> $> svn checkout svn+ssh://svn.server.somewhere/path/to/project/trunk
> the above will create a "trunk" directory in the directory they
> execute the command. They will work on their source code then
> $> svn commit
> and write a comment. That will commit their changes to the "trunk"
> directory in the project tree, right?

Right. So far so good.

> Next, lets say that the project is in a state that the version at
> the time is a "release", source code to be given to anyone else.
> That "release" is created by tagging that working version in trunk
> directory?

Yes, that's the most common use for tags. If you've decided that the
state of trunk right now is going to be called "version 1.0" of your
software, then you would copy it to a new tag called 1.0:

$> svn copy \
svn+ssh://svn.server.somewhere/path/to/project/trunk \
svn+ssh://svn.server.somewhere/path/to/project/tags/1.0 \
-m "Tagging trunk as 1.0"

Tags are explained in the book:


> Finally, lets say two programmers want to work on newly checked out
> version but each of their changes are some major changes. So they
> can make a branch from themselves, work on that branch and commit
> back their changes into their own branches, and then some time
> later "merge" those branches back into the trunk?

Yes, that's what the book calls a feature branch, one of the common
uses for branching:


(That's kind of in the middle of the chapter and it refers to things
earlier in the chapter, so you may want to start reading at the top
of the page.)

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 11 00:09:19 2007

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.