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
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
|
Contributed to CvsGraph by Henrik Carlqvist <henca@users.SourceForge.net>
Original: Sun, 2 May 2004 20:42:47 +0200
Modified: Tue, 24 Aug 2004 19:13:45 +0200
Included: Sun, 29 Aug 2004 14:30.00 +0200
-------------------------------------------------------------------------
Hello and thanks for cvsgraph which is a great program!
We used to manually draw ascii-graphics do document our tags and branches.
Then we found cvsgraph which could automatically draw graphs for us.
Unfortunately CVS by itself does not keep the information that is needed to
find out on which branch a tag belog. If a file on a branch is unmodified
compared to the main trunk CVS behaves as if all tags also were on the main
trunk even though they belong to a branch.
The solution was a few CVS scripts which creates a new file which exist only
to keep track of tags and branches. I hope that more people will find these
scripts useful and include them in this email as attachements. The included
files belong to $CVSROOT/CVSROOT/
The file tag_action.sh creates and maintains a file called .cvs_tag_tracer
which has the information we need about which tags belongs to which branches.
The file commit_action.sh adds an extra tag to .cvs_tag_tracer at a cvs commit
after a cvs update -j, this is to trace merges with cvsgraph.
The file checkoutlist is modified to list our two new files in CVSROOT.
The file cvswrappers make sure that the file .cvs_tag_tracer always is copied
and not merged. This is necessary to trace merges and to avoid conflicts at
updates and merges.
The file taginfo makes sure that our file tag_action.sh is called at "cvs
tag".
The file commitinfo makes sure that our file commit_action.sh is called at
"cvs commit".
For cvsgraph to trace merges with the system above I have the following in
cvsgraph.conf:
merge_from = "^(.*)";
merge_to = "^(.*)merged_%1$";
Finnaly I have made some minor changes to cvsgraph, these changes are included
in ugly_hack.diff. (BSnote: included since 1.5.1)
First it seems as if the time stamps in our cvsroot are utc-time. For the
graph to present the correct local time I had to add the row
"t -= timezone;". (BSnote: included since 1.5.0 and fixed again in 1.5.1)
Then as we are now tracing our .cvs_tag_tracer which is not really a part of
the source code we are no longer interested in any revision numbers of that
file. Therefore in my patch, the revision numbers are no longer presented.
Unfortunately I was and still am very short of time and this applies to all of
us in our project. The right way to do this patch would be to add some kind of
configuration option, but now the patch simply removes any revision info.
The third thing the patch does is that it hides the tag name of our special
merge tag. This is because that tag is only set on the file .cvs_tag_tracer,
the other files doesn't have that tag so we don't want to present it.
There are a few prerequisites and limitations:
As the scripts are unix scripts CVS must be run on unix. The CVS archive must
be in the file system, not on a CVS server. A recent version of CVS is
needed. 1.11 works, 1.9 does not work. I don't know about 1.10. Everything
seem to work with 1.9 except tracing merges, this is because "-m 'COPY'" in
cvswrappers does not behave as expected. New tags can only be created at the
end of a branch or main-trunk. After a "cvs update -j" you have to do a "cvs
commit" before doing any more "cvs update", otherwise the information about
the first "update -j" will be lost in .cvs_tag_tracer.
A file .cvs_tag_tracer will be created in every directory. Because of this I
have also made a patch to cvs2html which we use to hide that file.
I hope that you will find the attached scripts useful. Feel free to do
whatever you wish with them. I also apologize for my ugly hack, I wish that I
would have had the time to do this the right way. If you think that my scripts
mean more work than it is worth or have to much limitations you could simply
ignore this email.
Best regards Henrik
|
