[TYPO3-core] TYPO3_4-0-0 tagged in CVS / merge back to HEAD?

[Dmitry Dulepov]

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

Hi!

Michael Stucki wrote:
> Of course. The problem is just that a lot of files have been removed (dmailer 
> class), moved (gfx) or added (e.g. t3skin). I thought there is an easy way to 
> adapt this from the 4.0 branch...

Well, there is no solution in CVS for moving except operating CVS
repository directly on the server (physically moving CVS directories
there). But this action ruins previous versions, so not acceptable. In
our case gfx and other *moved* directories will be removed in HEAD and
recreated in different place as a new directory (so, all versiong
information for them will start from scratch). As to other operations
(adding, deleting), this is not problematic. Here is main piece of
information from the manual:

http://ximbiot.com/cvs/manual/cvs-1.12.13/cvs_5.html#SEC62:
=====================
You can merge changes made on a branch into your working copy by giving
the `-j branchname' flag to the update subcommand. With one `-j
branchname' option it merges the changes made between the greatest
common ancestor (GCA) of the branch and the destination revision (in the
simple case below the GCA is the point where the branch forked) and the
newest revision on that branch into your working copy.

The `-j' stands for ?join?.

Consider this revision tree:
 	

+-----+    +-----+    +-----+    +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !      <- The main trunk
+-----+    +-----+    +-----+    +-----+
                !
                !
                !   +---------+    +---------+
Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
                    +---------+    +---------+

The branch 1.2.2 has been given the tag (symbolic name) `R1fix'. The
following example assumes that the module `mod' contains only one file,
`m.c'.
 	
$ cvs checkout mod               # Retrieve the latest revision, 1.4
$ cvs update -j R1fix m.c        # Merge all changes made on the branch,
                                 # i.e. the changes between revision 1.2
                                 # and 1.2.2.2, into your working copy
                                 # of the file.
$ cvs commit -m "Included R1fix" # Create revision 1.5.

A conflict can result from a merge operation. If that happens, you
should resolve it before committing the new revision. See section
Conflicts example.

If your source files contain keywords (see section Keyword
substitution), you might be getting more conflicts than strictly
necessary. See Merging and keywords, for information on how to avoid this.

The checkout command also supports the `-j branchname' flag. The same
effect as above could be achieved with this:
 	
$ cvs checkout -j R1fix mod
$ cvs commit -m "Included R1fix"

It should be noted that update -j tagname will also work but may not
produce the desired result. See section Merging can add or remove files,
for more.
=====================

and http://ximbiot.com/cvs/manual/cvs-1.12.13/cvs_5.html#SEC65

=====================
 5.9 Merging can add or remove files

If the changes which you are merging involve removing or adding some
files, update -j will reflect such additions or removals.

For example:
 	
cvs update -A
touch a b c
cvs add a b c ; cvs ci -m "added" a b c
cvs tag -b branchtag
cvs update -r branchtag
touch d ; cvs add d
rm a ; cvs rm a
cvs ci -m "added d, removed a"
cvs update -A
cvs update -jbranchtag

After these commands are executed and a `cvs commit' is done, file `a'
will be removed and file `d' added in the main branch.

Note that using a single static tag (`-j tagname') rather than a dynamic
tag (`-j branchname') to merge changes from a branch will usually not
remove files which were removed on the branch since CVS does not
automatically add static tags to dead revisions. The exception to this
rule occurs when a static tag has been attached to a dead revision
manually. Use the branch tag to merge all changes from the branch or use
two static tags as merge endpoints to be sure that all intended changes
are propagated in the merge.
=====================

So, what you can do is:
1. Check out TYPO3_4-0 branch to location #1.
2. Check out HEAD branch with -j option to location #2.
3. diff these two location, you should have no differences except in CVS
doiirectories. Alternatively use CVS diff against TYPO3_4-0 branch.
4. If no differences found, commit HEAD.

* * *

I think we should do the following in the future:
1. Main stream development always goes in HEAD.
2. Maintanace releases (like those 3.7.1, 3.8.1, 4.0.1) should go to the
branch because there are no really major changes in them -> easier to merge
3. Version are always tagged (i.e. TYPO3_4-0-0) in the corresponding
branch (i.e. TYPO3_4-0-1 is tagged in its own branch, not in the head)

This way we will not have to merge main development to head but need to
merge only small maintainace fixes (or better commit them to both
branches at the same time).

Dmitry.
- --
"It is our choices, that show what we truly are,
far more than our abilities." (A.P.W.B.D.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFEOhuDRVcYnKJ8N6kRAi4fAJ4k5MPcZ5L/A1gmwWNNTgb2I0ogOQCgtYYC
tiU/ko5ug+XimVqtD65DtLY=
=6mbN
-----END PGP SIGNATURE-----