forked from apache/logging-log4j1
-
Notifications
You must be signed in to change notification settings - Fork 0
/
BRANCHES
61 lines (44 loc) · 2.37 KB
/
BRANCHES
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
Given that log4j 1.3 is not likely to be released before a few months,
I have created a branch called v1_2-branch in our CVS repository. The
branch was created by issuing the following command:
cvs -d :ext:ceki@cvs.apache.org:/home/cvs rtag -b -r v1_2final v1_2-branch jakarta-log4j
Using the 1.2 branch, we can incorporate patches to log4j version 1.2
while version 1.3 continues to be developed on the main trunk. For
example, we can officially release LogFactor5 (including
documentation) already in log4j 1.2.1.
The command to access the v1_2-branch is:
cvs -d XYZ checkout -r v1_2-branch jakarta-log4j
where XYZ is the remote repository name, that is
":ext:ceki@cvs.apache.org:/home/cvs" for me.
Alternatively, you can issue following update command from within any
existing work copy.
cvs update -r v1_2-branch
Working with branches is not completely trivial and requires a little
coordination between committers, in particular in relation with branch
merge operations. In order to avoid multiple merge conflicts, each
time we merge from the 1.2 branch to the main trunk, we should tag the
merged version on the 1.2 branch. Subsequent merges should use the tag
referring to the latest merged version of the branch. Also do not
forget to publicly announce a merge operation.
I am suggesting that (1.2 -> trunk) merge operations be done in a
concerted manner. Before doing a merge you tell everyone that you are
going to do a merge, you execute the merge operation, and then tag the
merged version on the 1.2 branch, for example v_1_2_-merged-bug666
The *next* merge operation would be performed as
cvs update -j v_1_2_-merged-bug666 -j v1_2-branch
from within a working copy of the *trunk*. This merge operation would
obviously also need to be tagged. According to the CVS manual, this
procedure eliminates the side effects of merging already merged
changes.
Bug fixes should and documentation improvements, should be made to the
1.2 branch, not the trunk. I'll take care of merging the changes to
the main trunk.
If this sounds like mambo jumbo, I urge you to consult the CVS
documentation and experiment with branches before hitting the log4j
repository. Branches are not that complicated really although they
require slightly more discipline on the part of committers. Do not
hesitate to shout if you need help.
If you have a better alternative for working with branches please let
us know.
--
Ceki