Re: Import and merge into branch

[Mark D. Baushke]

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

Erik Andersson <address@hidden> writes:

> So it's really now risk in creating the branches directly from the
> release version tags?

There is no risk that cvs will get something confused. (The same may not
be true for yourself.)

> Someone told me that this would be a risk for CVS to get confused. 

There is no risk of cvs getting confused by creating a new branch from a
version tag of any kind.

> 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 ;-)

Nah, I am giving you free advice and it is only worth what you pay for
it. :-)

> 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.

Hmmm... that was not a part of your original problem statement. Mapping
versioning from one system to another can be very tricky. If you have a
process worked out for you already, I'd suggest you stick to it.

> 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:  

I'll add a few remarks in-line.

        -- Mark

> 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. 

Future direction change:
The cvs 1.12.10 (not yet released) will have a -X option to import that
allows you to import and not be visible on the main trunk by default.
Version 1.1 exists (it always needs to be created) and version 1.1.1.1
is the first imported version, then with -X a dead 1.2 version is
created right away. This protects the main trunk from imports that might
confuse it and allows you to merge vendor files into the main trunk in
a controlled commit in conjunction with other mainline files.

> 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. 

Actually, it is possible for a branch to be a decendent of another
branch for cvs, not everything must be in either a two digit (main
trunk) or four digit (branch off of main trunk) number space.

> Each branching point for creating each branch must be extracted. 

Yes., the point seems obvious.

> Each branch must be extracted in "latest'n'greatest" state - ie. head of
> each branch. 

Yes, for a mapping between two source control systems, this is a
reasonable assumption.

> All branching point must be known date-wise to import into CVS in
> correct order.. 

This can be difficult to do if some branches were truely done in
parallel and happened 'at the same time' in the other source control
system. It also does not really help with mapping branches of branches.
This can be done with some difficulty and confusion by using explicit
'cvs import -b 1.1.3 module vendor2 vendor2-version' kinds of tricks,
but that way usually involves madness and years spent in therapy...

You may find importing successive time-based snapshots into the new
repository and using the '-d' flag to keep time and date around as in
'cvs import -d module vendor vendor-version' to be useful.

> Head of main trunk must be extracted. 

Yup.

> A state previous to the earliest branching point must be extracted from
> main trunk. 

Yup.

> It is important to beware of the fact that the last import dictates how
> main trunk looks in the final state. 

True modulo conflict resolution or local commits to the main trunk as well
as the possibility of the '-X' option to import.

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

Yes, you really don't want to lose the previous release tag by resuing
it. Keep them all unique. Reusing the vendor tag is a good idea, but not
necessarily a big deal if you make an oops (modulo using the -b switch).

> 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. 

Good idea.

> Import each branching point in reverse date order. 

Reasonable.

> Import each branch-head. 

Hmmm... possibly, depending on what is meant by this.

> Import the comming ancestor (the oldest main trunk state). 

Yup.

> Force commit of main trunkt to set all revisions to 1.2. 

See use of the -X option above...

> 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. 

Yup.

> 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. 

I am not sure this is necessarily reasonable or correct or desirable.

> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFBhcLM3x41pRYZE/gRAvwoAKCp8SMaPNr34Uy86zPHX5AUjxAhowCg17da
pQeak59XvMhsY2XWyhwHP3I=
=Js6v
-----END PGP SIGNATURE-----