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

RE: RE: Subversion's repositories

From: Ignacio Gonzalez T. <igtorque_at_eliop.es>
Date: 2006-12-05 16:09:59 CET

El 5 Dec 2006 a las 15:42, Chris.Fouts@qimonda.com escribió:

In a normal development environment, trunk and branch dev/v1 (or any branch)
are "parallel" development cycles, meaning, new code may besubmitted to both
in parallel. So once the trunk changes, it's no longer in "sync" with the branch.
Conversely, once the branch changes, it's no longer in sync with the trunk. Ok so


Even if the trunk does NOT change in parallel, that is, if ALL development is done
on dev branch, one will still have to create tags on BOTH trunk and branch since
they signify the last the time the branch was merge with trunk (trunk tag), and the
last time trunk was merged with branch (branch tag)

To resync the branch with the trunk, one would have to "svn merge" the "delta"
between the trunk and branch, which is, the code from branch-pont to HEAD. In
SVN terms this means
> cd to branch sandbox (important step!!!)
> svn merge //svn_root/project1/tags/trunk-to-dev_v1 //svn_root/project1/trunk
> (resolve conflicts)
> svn commit
Now the branch is in sync with the trunk. For future merges, one will have to
move the trunk tag.
> svn del //svn_root/project1/tags/trunk-to-dev_v1
> svn cp //svn_root/project1/tr //svn_root/project1/tags/trunk-to-dev_v1

Now to resync the trunk with the branch, the converse operation from above, one
would need to "svn merge" the "delta" between branch and trunk, which is, the
last time the branch was in sync with trunk to latest branch code. In SVN terms
this means
> cd to trunk sandbox (important step!!!)
> svn merge //svn_root/project1/tags/dev_v1-to-
> (resolve conflicts)
> svn commit
Now the trunk is in sync with the branch. For future merges, one will have to
move the branch tag.
> svn del //svn_root/project1/tags/dev_v1-to-trunk
> svn cp //svn_root/project1/branches/dev/v1 //svn_root/project1/tags/dev_v1-to-

Clear as mud?

I see. What was confusing me was the notion "tags represent revision trees
frozen at a certain time". So, in my mind, trunk-to-dev_1 and dev_1-to-trunk
represented the same revision tree not only at the beginning of the branching, but
also forever.

I got this idea somehow reading the svn book, without realising that tags can be
reused! In fact, a reused tag in svn -as you describe it- is similar to the notion of
"floating labels" (used for ongoing development) versus "fixed labels" (used for
signaling releases, etc.) that I use with RCS and PVCS.

Thanks for the clarification.

Ignacio González.

    From: Ignacio Gonzalez T. [mailto:igtorque@eliop.es]
    Sent: Tuesday, December 05, 2006 3:01 AM
    To: users@subversion.tigris.org
    Subject: RE: Subversion's repositories
    Just a question for Chris, from a green subversioner:

    Why do you fell necessary to tag trunk-to-dev_v1 AND dev_v1-to-trunk?
    How does it make it easier to merge between dev_v1 and trunk?


    Ignacio González

    El 4 Dec 2006 a las 16:28, Chris.Fouts@qimonda.com escribió:

    Date sent: Mon, 4 Dec 2006 16:28:57 +0100
    From: <Chris.Fouts@qimonda.com>
    To: <users@subversion.tigris.org>
    Subject: RE: Subversion's repositories

    I have a couple of suggestions.

    First off, set your repository structure "outside" of Subversion, and then "svn
    import" it. With this approach, adding and deleting dirs/files is easier since
    you do NOT have to deal with Subversion yet.

    Second, there are 1001 different ways to do the dir structure, but I suggest
    the following; I'm assuming that priject1, project2, are NOT related

     (same fundamental structure as for project1)

    I'm ONLY suggesting the structure because this facilitates "logical"
    and tagging. For example, for branching
    - You set up your trunk structure first
    - Then you "svn copy" your trunk structure to your branch structure
> svn mkdir //svn_root/project1/branches/dev
> svn mkdir //svn_root/project1/branches/qa
> svn cp //svn_root/project1/trunk //svn_root/project1/branches/dev/v1
> svn cp //svn_root/project1/trunk //svn_root/project1/branches/qa/v1
    - Create tags to facilitate merging between trunks and branches, both
     on the trunk and the branches, as soon as you create the branches
> svn cp //svn_root/project1/trunk //svn_root/project1/tags/trunk-to-dev_v1
> svn cp //svn_root/project1/branches/dev/v1
    //svn_root/project1/tags/dev_v1-to- trunk
> (similar for qa branch)

    Like I said, this is just "a" way to do it, and not necessarily "the" way.

    From: T. Nguyen [mailto:ptn_y2k1@yahoo.com]
    Sent: Sunday, December 03, 2006 12:40 AM
    To: users@subversion.tigris.org
    Subject: Subversion's repositories Hi,

    I am setting up a Subversion server. As I read several books and searched
    on the internet, I have not seen any complicatedrepository structure as my
    workplace requested. Please see thefollowing structure:

    (trunk, tags, branches)
    (trunk, tags, branches)
    (trunk, tags, branches)
    ................(same structure as dev)

    Here are my questions that I need your helps.

    1. Is it possible to have that kind of structure in Subversion? If yes, is it a
    good or bad structure? And is it easy to maintain later? If no, please give
    me your advise what I should do?
    2. If it's possible, whichlevel should I use 'svnadmin create' and whichlevel
    should I use'svn mkdir'?

    I am looking forward to receiving your response. Thank you very much.


Ignacio González Torquemada
Pol. Ind. Alcobendas
Avda. Valgrande, 8
28108 Madrid
Tel. (+34) 91 383 57 47
Fax. (+34) 91 302 92 49
e-mail: igtorque@eliop.es
Este correo electrónico y cualquier fichero adjunto al mismo contienen información de carácter confidencial 
exclusivamente dirigida a su destinatario o destinatarios. En el caso de haber recibido este correo electrónico por 
error, se ruega notificar inmediatamente esta circunstancia mediante reenvío a la dirección electrónica del remitente 
y destruir el mensaje.
P Antes de imprimir este correo, piense en su responsabilidad y compromiso con el medio ambiente

The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

   ---- File information -----------
     File: eliop_logo_Pegasus.jpg
     Date: 12 Sep 2006, 10:43
     Size: 5206 bytes.
     Type: Unknown

Received on Tue Dec 5 16:11:47 2006

This is an archived mail posted to the Subversion Users mailing list.