Re: Issuezilla #175: Add new -F style option that only allows tag to move to newer revision

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Geoffrey Lowney <Glowney@rei.com> writes:

> I submitted this patch (including tag.c, sanity.sh and cvs.texinfo
> patches for my enhancement) back at the start of April, and there has
> been no response yet.  Derek suggested I post to bug-cvs@gnu.org with a
> link to the issue (the link is below).
> 
>  
> 
> The enhancement is as follows:
> 
>  
> 
> I have created an enhancement to the 1.12.6 version of tag.c to support
> our automated build process.  The new version adds a -u option (-u is
> shorthand for -up).  It is almost identical to -F, except it only allows
> tags to be moved to newer revisions.  I'd like to have this enhancement
> added to the standard CVS codebase so I don't have to keep implementing
> it for each release.
> 
>  
> 
> http://ccvs.cvshome.org/issues/show_bug.cgi?id=175

The code as written would not stop users from moving the tag to a
separate branch (compare_revnums will not return an accurate result
unless the two revision numbers have the same number of fields).

Is that desirable?

Given the following set of revisions for a particular file given in
time-order as applied to the repository:

   1.1 1.1.2.1 1.2 1.1.2.2 1.3 1.1.2.3 1.1.4.1 1.1.4.2 1.1.2.4 1.4 1.5

If we assume that a tag is placed on one of the versions such as
1.1.2.3, would it really be valid to move to 1.3 with the new -u flag?
After all, 1.3 might actually 'older' than the 1.1.2.3 version. If the
tag is on 1.2, should it be allowed to go to 1.1.4.1 which might or
might not be a descendent version of 1.2?

Should newer be in terms of the modification time of the change rather
than just in terms of the revision number of the change?

Should the move be allowed only if the old version is a ancestor of the
new version?

I suggest that these issues be considered and a more rigerous definition
of what 'newer' means in the context of multiple branches and revisions
be defined before this patch get incorporated into the cvshome sources.

I do like the idea of being able to have a more restricted forced
update, I just want to make sure that it is well defined what the new
feature means and that test cases are generated that exercise all of
those conditions.

        Thanks,
        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFAl8Vu3x41pRYZE/gRApapAKCvf0erx19fU6+NUS2idjQIfSY2jgCeK6JH
OF5LM49Nrp2Yf5SEjHKNbTU=
=dxhr
-----END PGP SIGNATURE-----