[Nut-upsdev] Re: About CVS usage of tags and branches in NUT (was: CVS branches?)

[Charles Lepple]

On 8/17/05, Niels Baggesen <nba at users.sourceforge.net> wrote:
> On Wed, Aug 17, 2005 at 08:47:25AM +0200, arnaud.quette at mgeups.com wrote:
> > I hear you but:
> > 1) tagging each release make redundancies with the existing patchs
> > and tarballs (for each stable and testing, there's a patch _and_ a
> > tarball). Looking at the CHANGES file help to see what has changed
> > and when

I'm wondering if it isn't the patches that are redundant now. After
all, having tags allows you greater flexibility, such as being able to
retrieve diffs between any two versions.

At the risk of getting yelled at by the "NUT is bloated" camp, the
full source tree is small enough that I can download it over my cell
phone data connection without much pain. Having incremental patch
files is useful for projects with huge source trees, such as the Linux
kernel.

> > 2) the drop down list grows too quickly when tagging each stable/testing
> > release, with a result that I don't like (too much info == loss of info).

again, you can use a prefix on the tags to group together pre-release
tags, release tags, etc.

something to consider for down the road: since you can have arbitrary
paths for tags/branches in Subversion, you could have a tags directory
with subdirectories instead of prefixes. That way, if someone is
looking for release tags only, they don't see the listing cluttered
with pre tags.

of course, there are all sorts of other advantages with subversion,
such as changesets, and the ability to use characters such as dots in
tag names (and alioth's svn support seems about as reliable as their
CVS server, and maybe more so for anonymous access), but that's a
discussion for another time, and another thread.

> > So I'll continue with the same process: No tags for stable and testing,
> > and cvs tags for development.
> 
> I do not agree with you. It is absolutely vital, and one of the major
> reasons for using a souce code control system, that you easily can
> recreate ANY version, or check the differences between them.

I tend to agree with Niels, and I think it is backwards to have cvs
tags only for development branches.

Let's say someone has tested a release version, and is looking to find
out when a new feature got merged in. How are you proposing that they
find the feature? Should they search every patch file?

A compromise may be to use $Id$ tags in source files, although CVS
handling of keywords is still a little suboptimal, and causes merge
problems. My vote is for sticking with tags for at least stable and
testing.

-- 
- Charles Lepple