--------------------------------------------------
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
far?
OK
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-
trunk//svn_root/project1/branches/dev/v1
> (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-
trunk
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?
Regards,
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
svn_root
project1
trunk
web
job
branches
dev
v1
web
job
v2
web
job
qa
v1
web
job
v2
web
job
tags
project2
(same fundamental structure as for project1)
I'm ONLY suggesting the structure because this facilitates "logical"
branching
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:
svn_root
dev
project1_root
project1_web
project1_web_v1
trunk
tags
branches
project1_web_v2
(trunk, tags, branches)
project1_jobs
project1_jobs_v1
(trunk, tags, branches)
project1_jobs_v2
(trunk, tags, branches)
project2_root
.....
.......
.......
........
project3_root
qa
................(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.
Regards,
Tracy
--
Saludos,
Ignacio González Torquemada
INGENIERO SW - DPTO. PRODUCTOS
Pol. Ind. Alcobendas
Avda. Valgrande, 8
28108 Madrid
Tel. (+34) 91 383 57 47
Fax. (+34) 91 302 92 49
http://www.eliop.es
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