RE: Import and merge into branch

[Erik Andersson]

Thanks a lot again!!

So it's really now risk in creating the branches directly from the
release version tags? Someone told me that this would be a risk for CVS
to get confused. We have already spent to much time trying to fix this
so I really need to get this things  straighten out before I go talk to
my boss.. I would also appreciate other peoples say, although I think I
really should trust Mark ;-)

What we really wanted to do was to go from another versioning system to
CVS and and for this we used the import. We have a lot of projects
working across eachother and often working with the same files etc.

This is what's was sent to me and this is from what I am to understand
that this is the way for us to go:  

CVS Guidelines.
These guidelines are written on current experience with larges projects
having many parallel branches of the same source in various states.
Projects not having so much going on in parallel can get much easier off
than what these guidelines states. 

------------------------------------------------------------------------
--------

Converting from another project
If conversion from another versioning system is needed before using CVS,
then care should be taken if conversion must maintain existing current
development and/or multiple stages/milestones from the old versioning
system. 

CVS has a sort of odd way of using revision numbers when importing.
First revision is 1.1.1.1 and Not 1.1. However, when modifying a file in
main trunk the first change on that file will get revision 1.2! This is
quite important to notice as it is needed when changing to use CVS from
another versioning system at a time where active branches still exists. 

The following images/filesets are absolutely necessary when changing to
CVS and not loosing active states. 

The assumption is that all branches are decendents of main trunk and
that they are in parallel. 

Each branching point for creating each branch must be extracted. 
Each branch must be extracted in "latest'n'greatest" state - ie. head of
each branch. 
All branching point must be known date-wise to import into CVS in
correct order.. 
Head of main trunk must be extracted. 
A state previous to the earliest branching point must be extracted from
main trunk. 
It is important to beware of the fact that the last import dictates how
main trunk looks in the final state. 

When importing it is Vital to use the same vendor tag and a new release
tag for every new import. 

To make the import behave correctly and to get the desired result, the
following way of building the repository could be used: 

Import what is going to be head of main trunk. 
Import each branching point in reverse date order. 
Import each branch-head. 
Import the comming ancestor (the oldest main trunk state). 
Force commit of main trunkt to set all revisions to 1.2. 
Merge differences from imports to main trunk to create each branching
point in main trunk. Remeber to set a tag after each merge for
indentification. 
Branch of each branching point, checkout each branch and make a
recursive force commit. This gives revisions like 1.X.2.1 for all files,
where X is the version from main trunk. 
For each branch merge differences from import to create head of branch. 
For main trunk merge the last for setting the real head state. 
It is a lot of imports and merges, but you should end up with something
like: 
Main
  +---Import Head-of-main (1)
  |        |
  |   Import Branching-point-2 (2)
  |   Import Branching-point-1 (3)
  |   Import Branch-head-1 (4)
  |   Import Branch-head-2 (5)
  |        |
  |   Import Ancestor (6)
  |
 (A) <-- forced commit giving state of (6)
  |
 (B) <-- merge to branching-point-1 (-j ancestor -j branching-point-1)
  | \
  |  \---- Branching to branch-1
  |              |
  |         Forced commit + set start tag
  |              |
  |         Branch-1 head  <-- Merge to branch-2 head (-j
branching-point-1 -j branch-head-1)
  |
  |
 (C) <-- merge to branching-point-2 (-j branching-point-1 -j
branching-point-2)
  | \
  |  \---- Branching to branch-2
  |              |
  |         Forced commit + set start tag
  |              |
  |         Branch-2 head  <-- Merge to branch-2 head (-j
branching-point-2 -j branch-head-2)
  |
  |
 (D) <-- merge to Head-of-main (-j branching-point-2 -j head-of-main)


The resulting state (D) should be the production state. If this setup
should be carried out to create the branches according to the branching
strategy below, then a little further branching and forced commits are
necessary, but it is not especially complicated. 
------------------------------------------------------------------------
--------

Branching strategy
Branches should normally reference the current state of a given
environment. In this context with larger projects it gives: 
production
  |
  +---Test
       |
       +---Development

This mostly when a lot of developers are involved. 
Having a full environment with the above structure, then it becomes
almost vital that CVS is used correctly and that CVS is somewhat
prohibited from making errors when merging. This can be done by forcing
a commit on ALL files whenever creating a new branch. 

Production will always be carried in the main trunk of CVS and
everything else will be branched out from there. 

Taking the above into consideration, then when making a development
branch, which must be applied to Test before it goes to production, then
when making the Test branch, all files must be forced committed to make
the revisions correct before making the development branch. The issue
here is if this is not done, then the development branch will be a
parallel branch to the Test branch, which is not what you want. The
reason is that CVS does not assign a new revision to a file when
creating a branch - it either needs a change or a forced commit. 

As most environments also need bugfixing, then a branch for that would
usually come in very handy. My resulting branching structure thus
becomes to be like this: 

Production
  |
  +---prod-bugfix
  |
  +---Test
       |
       +---test-bugfix
       |    |
       |    +---patchXX
       |    +---....
       |
       +---Development-shared
            |
            +---ProjectA
            +---ProjectB
            +---....

Notes: 
The normal bugfix branch would be test-bugfix as prod-bugfix is only to
be used for emergencies. 
The patchXX branches could be "simulated" using pre/post tags in the
test-bugfix branch, which gives the endpoints for merges. 

Best Regards / Erik



-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Mark D.
Baushke
Sent: den 31 oktober 2004 16:47
To: Erik Andersson
Cc: address@hidden
Subject: Re: Import and merge into branch 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Erik Andersson <address@hidden> writes:

> OK, thanks a lot for your reply, but wouldn't this create the branch 
> from the "magic" import branch?

If you mean that newbranch will have a magic version number of something
like 1.1.1.1.0.2 and commits to it will look like 1.1.1.1.2.1, then yes.

> Is that really ok? 

Sure, I do it all the time.

> Is there no danger in creating branches from the revisions in a magic 
> branch?

The vendor branch is not a magic branch (unless you did something very
odd when you did the import with the -b option?), it is branch 1.1.1 and
you would be maging a 'magic branch' from the latest VENDOR-VERSION tag
which is not itself a branch.

        -- Mark

> Best Regards / Erik
> 
> -----Original Message-----
> From: address@hidden [mailto:address@hidden On Behalf Of Mark D.
> Baushke
> Sent: den 29 oktober 2004 18:15
> To: Erik Andersson
> Cc: address@hidden
> Subject: Re: Import and merge into branch
> 
> Erik Andersson <address@hidden> writes:
> 
> > I messed up and need to to a fresh import and then make a branch 
> > contain all from that import. How do I do? I only want that code in 
> > the branch and not into main..
> >
> > Can I use the original branch and somehow merge this into the
branch? 
> > 
> > Please help me out!!
> 
> Assuming you did
> 
>     cvs import module VENDOR VENDOR-VERSION
> 
> then something like this:
> 
>     cvs rtag -b -r VENDOR-VERSION newbranch module
>     cvs checkout -r newbranch module
> 
> should get what you want.
> 
>       -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFBhQkF3x41pRYZE/gRAu/sAKDMgISDuYEyiS2LPO91cSXTJOYz2QCfd8hf
C4y19fASes/ETRtLxqVllq8=
=jDtA
-----END PGP SIGNATURE-----