info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reduced performance related to the number of branches


From: Todd Denniston
Subject: Re: Reduced performance related to the number of branches
Date: Tue, 07 Feb 2006 08:09:03 -0500
User-agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)

simmo wrote:
I have been using CVS for some time now and regularly make use of
branches to carry out new lines of development without affecting the
core code base and as far as I am concerned it works very well.

A friend of mine has been using CVS for some time and also wants to
start making more use of branches, but he has had some opposition from
some of his team members. One of the main reasons they have come up
with, for not using branches is that when lots (not sure how many lots
are) of branches are created, the performance of CVS is greatly
reduced! I have never heard this ever mentioned before. I certainly
haven't read it on any posts on here, in the CVS book I have or after
doing a quick search on the web.

As I understand it, there is not a great deal of difference between a
tag and a branch both of which are  essentially entries in a file
somewhere in the repository. So I guess that the more entries that are
made the longer it could take to search for a given branch or tag name,
but as I see it the cost would be negligable. I also assume the same
could be said about creating lots of revisions of files as well.
<snip>

The tags to create the branches cost no more than a regular tag, but reconstructing versions that are on a very long lived branch can be some what more intensive, and diffs between points in two long lived branchs very intensive. Larry Jones explained it a bit in other messages on this list[1]. Basically as long as each new branch does not have much development on it before going back to the trunk, then the penalty of doing branches should be not a problem.

I believe the general consensus though is to do most development on the trunk with short lived branches for development that needs shielded from other changes, and long branches for stable releases. See the FAQ for some links and ideas[2].

Also a search of the mailing list[3] does not seem to bring up so many entries as to be difficult to read.

[1] http://lists.gnu.org/archive/html/info-cvs/2003-10/msg00192.html
    http://lists.gnu.org/archive/html/info-cvs/2003-10/msg00211.html
    http://lists.gnu.org/archive/html/info-cvs/2005-02/msg00151.html

[2] http://ximbiot.com/cvs/wiki/index.php?title=CVS_FAQ#What_is_the_best_branching_practice_to_use_with_CVS.3F
http://ximbiot.com/cvs/wiki/index.php?title=CVS_FAQ#Source_Configuration_Management_Best_Practices

[3] http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=performance+AND+branch&submit=Search%21&idxname=info-cvs&max=20&result=normal&sort=score

--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter




reply via email to

[Prev in Thread] Current Thread [Next in Thread]