[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
Mark D. Baushke
Re: Issuezilla #175: Add new -F style option that only allows tag to move to newer revision
Tue, 04 May 2004 09:31:42 -0700
-----BEGIN PGP SIGNED MESSAGE-----
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 email@example.com 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.
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 126.96.36.199 1.2 188.8.131.52 1.3 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 1.4 1.5
If we assume that a tag is placed on one of the versions such as
126.96.36.199, would it really be valid to move to 1.3 with the new -u flag?
After all, 1.3 might actually 'older' than the 188.8.131.52 version. If the
tag is on 1.2, should it be allowed to go to 184.108.40.206 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
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
-----END PGP SIGNATURE-----