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

[Geoffrey Lowney]

Thanks for you feedback Mark.  Please note me responses below.

Geoffrey A. Lowney 
Senior Software Development Engineer 
Recreational Equipment, Inc. 
Phone 253-395-8164 Fax 253-437-7291 
Pager 206-625-8477 2066258477@page.metrocall.com 
glowney@rei.com http://www.rei.com/

> -----Original Message-----
> From: Mark D. Baushke [mailto:mdb@cvshome.org]
> Sent: Tuesday, May 04, 2004 9:32 AM
> To: Geoffrey Lowney
> Cc: bug-cvs@gnu.org
> Subject: Re: Issuezilla #175: Add new -F style option that only allows
tag
> to move to newer revision
> 
> -----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?

Desirable?  Perhaps not, but in my case I didn't actually care, and I
was not sure how to address the problem (if it is one).  My existing
solution, while not necessarily satisfactory for every application,
still seems better than the current alternative (-F, which is wide open,
and would still be available).

> 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 think I prefer your latter definition.  Essentially, in our process we
are using tags to reflect versions of code that are ready for promotion.
In this way, a tag can be viewed as representing code that satisfies
some requirements.  We assume that a descendent revision of the code
continues to satisfy the requirements (or a desired change to them)
while an ancestor or parallel revision may not.

So I would say that -u should be defined to only allow the tag to move
to a descendant of the old revision.  -F would still be available if
someone needs to move the tag to a parallel revision.  I suppose we
could also have a second option that behaves as my -u option does today
(allowing movement across branches).

But I am not sure how to check that one revision is a descendant of
another.  Does anyone know if there an existing function in the code
(similar to compare_revnums) that would work?  Or will I end up having
to implement a new is_descendant function to enforce this new rule?

> 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.

Do you have specific test cases you would like to see added?  I just
made up a few based on how I originally thought the option might be
used.

>       Thanks,
>       -- Mark
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (FreeBSD)
> 
> iD8DBQFAl8Vu3x41pRYZE/gRApapAKCvf0erx19fU6+NUS2idjQIfSY2jgCeK6JH
> OF5LM49Nrp2Yf5SEjHKNbTU=
> =dxhr
> -----END PGP SIGNATURE-----