[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [task #4633] GPG-Signed Commits

From: Mark D. Baushke
Subject: Re: [task #4633] GPG-Signed Commits
Date: Mon, 19 Sep 2005 12:59:34 -0700

Hash: SHA1

Derek Price <derek@ximbiot.com> writes:

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

Yup, I agree. I just thought it was important to cover those issues and
possibly see if anyone has any patches laying around that they wanted to
contribute that does those jobs already (not likley, but possible).

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

Yeah, I understand.

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

Yes, sorry about the cut-n-paste error. I agree it is more likely a
1.13.x feature.

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

GPG also has the --textmode switch if we know that a file is not a -kb

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

True, but the code should be fairly simple. I might try to hack this one
out if I get a free weekend sometime in the next month or so.

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

Yeah, I know it is a feature with problems. I don't think I would use
it, but I understand any Ant users might find it more intuitive.

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


        -- Mark
Version: GnuPG v1.2.3 (FreeBSD)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]