Re: [task #4633] GPG-Signed Commits

[Derek Price]

Mark D. Baushke wrote:

> I have no real objection. I think it is reasonable to list
> the stuff that folks have submitted to the lists or the old
> www.cvshome.org issuetracker that may wish to be considered
> for 1.12.x before it becomes 'stable'.


<http://savannah.nongnu.org/task/index.php?func=detailitem&item_id=4686>
I've create the above task and made it dependant on some of your
wishlist.  I would love to get through all your wish list, but I think
it would be far more worthwhile to have the new features in 1.12
stabilized than it is to wait on so many new features with no volunteers
to write the code.

More below:

>   - 'cvs import' goes through a pre-import trigger (be it a
>     new trigger or be it a combination of commitinfo and
>     taginfo)
>     https://ccvs.cvshome.org/issues/show_bug.cgi?id=157


I've created
<http://savannah.nongnu.org/patch/index.php?func=detailitem&item_id=4441>
to track this, but I have not made the stabilizing of 1.12.x dependent
on it.  It would be one thing if we had a complete patch submission or
someone stating clearly that they will do the work soon, but so far we
do have neither.

>   - Updated diffutils.


<http://savannah.nongnu.org/task/?func=detailitem&item_id=4687>
This is fine, I will likely make time to do this.

>   - The Frank Hemer <frank@hemer.org> newtags feature.


<http://savannah.nongnu.org/patch/?func=detailitem&item_id=4443>
I really do want to see this in, at least the commitid stuff, especially
as it is half-completed.  I may take a look at how hard the tests will
be to write.

>   - A change to 'cvs add', either it goes through a
>     commitinfo trigger for new directories (it also needs to
>     get a CVS/Template populated when it is created which
>     seems to be a minor bug), or going with Greg A Woods
>     <woods@weird.com> suggestion to defer the connection to
>     the server until the 'cvs commit' has been issued (ie,
>     make cvs add client/server semantics like cvs rm
>     symmetric). The thread is here:
>     http://lists.gnu.org/archive/html/info-cvs/2005-02/msg00014.html
>     There is a long-standing issue here:
>     https://ccvs.cvshome.org/issues/show_bug.cgi?id=2


<http://savannah.nongnu.org/patch/?func=detailitem&item_id=4442>
Without code or a volunteer I do not think it is worth delaying the 1.13
release for the directory stuff, but I might tweak the `cvs add' to not
connect for files.  I've been thinking about that for awhile.

>   - GPG-signed feature.


<http://savannah.nongnu.org/task/?func=detailitem&item_id=4633>
I will answer the issues you raise about GPG-signed commits in a
separate email.

>   - cvs output should be able to support xml to allow
>     projects like cvslib and other cvs clients to more
>     effectively communicate with the server.
>     /issues/show_bug.cgi?id=157


This would be nice, but also means a lot of work, and most likely a new
dependency on an external library.  I do not think it is worth delaying
1.13 for this without a patch or even a volunteer to code one.

And cvshome.org issue #157 was the importinfo stuff.  Did you mean this
issue <https://ccvs.cvshome.org/issues/show_bug.cgi?id=160>?

>   - Per recent discussions on Unicode, the possibility of a
>     new feature that is orthogonal to keyword expansion that
>     controls if line endings conversion should take place or
>     not. (This may be desirable for GPG-signed form in any
>     case.)


<http://savannah.nongnu.org/patch/index.php?func=detailitem&item_id=4445>
This isn't strictly necessary with GPG-signed commits.  GPG-signed
commits only needs to perform any conversion in advance of signing and
delay conversion until after verification.  If someone changes the mode
retroactively for a file, they may have to resign some revisions, but
that shouldn't happen very often.  If I have time I may look into this.

>   - Desire the ability to deal with execute bits between
>     'cvs rm' and a new 'cvs add' of the same filename.
>     Possibly a new admin command to change the execute bits
>     on the repository file?
>     https://ccvs.cvshome.org/issues/show_bug.cgi?id=115


<http://savannah.nongnu.org/patch/index.php?func=detailitem&item_id=4446>
Not worth delaying 1.13 over without code.

>   - Some folks desire a way for 'cvs import' and possibly
>     'cvs add' to have a method to determine keyword
>     substitution for new files
>     https://ccvs.cvshome.org/issues/show_bug.cgi?id=1


<http://savannah.nongnu.org/patch/index.php?func=detailitem&item_id=4447>
Not worth delaying over without a patch submission.

>   - Some folks desire an option to 'cvs update' to make the
>     time of the updated file be the commit timestamp rather
>     than the update timestamp.
>     https://ccvs.cvshome.org/issues/show_bug.cgi?id=150


<http://savannah.nongnu.org/patch/index.php?func=detailitem&item_id=4448>
I'm not sure I like this feature anyhow (see my comments in the issue)
and it's certainly not worth delaying over without code.

>   - As a robustness, when LockDir is not being used, it may
>     be desirable to prohibit directories that look like cvs
>     internal lock files.
>     https://ccvs.cvshome.org/issues/show_bug.cgi?id=183


<http://savannah.nongnu.org/bugs/?func=detailitem&item_id=14591>
This is fine.  There is a patch.  I will get to it if no one else does.

> CVSNT 'features' that I have heard mentioned might be
> 'useful' to port back to CVS are:
>
>   - the 'mergepoint' feature
>
>   - the 'LockServer' (faster and more granular locks) feature


Would be nice, but not worth delaying over without a patch submission.

>   - the 'access control lists' feature


What's that?

>   - pluggable server-side diff programs (I do not believe
>     that pluggable server-side diff programs are going to be
>     useful if the GPG-signed feature is enabled).


No, but pluggable client-side diffs might still be useful.  A little
more trouble for server administrators, but doable.  Regardless, I don't
really want to plan on this without a patch submission.

Regards,

Derek
-- 
Derek R. Price
CVS Solutions Architect
Ximbiot <http://ximbiot.com>
v: +1 717.579.6168
f: +1 717.234.3125
<mailto:derek@ximbiot.com>