[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issuezilla #175: Add new -F style option that only allows tag to mov
RE: Issuezilla #175: Add new -F style option that only allows tag to move to newer revision
Tue, 4 May 2004 10:38:48 -0700
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 address@hidden
> -----Original Message-----
> From: Mark D. Baushke [mailto:address@hidden
> Sent: Tuesday, May 04, 2004 9:32 AM
> To: Geoffrey Lowney
> Cc: address@hidden
> Subject: Re: Issuezilla #175: Add new -F style option that only allows
> to move to newer revision
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Geoffrey Lowney <address@hidden> 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
> > been no response yet. Derek suggested I post to address@hidden
> > 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
> > our automated build process. The new version adds a -u option (-u
> > shorthand for -up). It is almost identical to -F, except it only
> > tags to be moved to newer revisions. I'd like to have this
> > added to the standard CVS codebase so I don't have to keep
> > 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 22.214.171.124 1.2 126.96.36.199 1.3 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 1.4 1.5
> If we assume that a tag is placed on one of the versions such as
> 22.214.171.124, would it really be valid to move to 1.3 with the new -u flag?
> After all, 1.3 might actually 'older' than the 126.96.36.199 version. If the
> tag is on 1.2, should it be allowed to go to 188.8.131.52 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
> 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
> of what 'newer' means in the context of multiple branches and
> be defined before this patch get incorporated into the cvshome
> 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
> -- Mark
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (FreeBSD)
> -----END PGP SIGNATURE-----
- RE: Issuezilla #175: Add new -F style option that only allows tag to move to newer revision,
Geoffrey Lowney <=