[TYPO3-core] IMPORTANT: CVS HEAD is back! (was: Re: TYPO3_4-0-0 tagged in CVS / merge back to HEAD?)
Michael Stucki
michael at typo3.org
Mon Apr 10 13:34:10 CEST 2006
Thanks Dmitry, that was indeed very easy! All went fine, there were no
errors.
This means:
- You can immediately commit pending patches that have been approved
already.
- HEAD is open for further development again (I expect Kasper might want to
write some lines about further plans first...)
- Keep in mind that bugfixes should be committed to both branches now
(TYPO3_4-0 + HEAD) if you think it makes sense.
- No(!!) features for the TYPO3_4-0 branch, just as before
- Please start again to write the affected branches in your patch request
(just as we used to).
Regards, michael
> -----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-----
--
Use a newsreader! Check out
http://typo3.org/community/mailing-lists/use-a-news-reader/
More information about the TYPO3-team-core
mailing list