There's some weird post-commit hook bugs on our CVS server. Anytime
somebody commits to the notes/ dir, some hook tries to do something
stupid. Yes, it went through. Just ignore the stupid hook errors.
Kevin Pilch-Bisson <kevin@pilch-bisson.net> writes:
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> Does this actually show up? I got the following strange message from
> CVS when I committed:
>
> checking in multi-args.txt;
> /cvs/subversion/notes/multi-args.txt,v <-- multi-args.txt
> new revision: 1.4; previous revision: 1.3
> done
> Processing log script arguments...
> Mailing the commit message to cvs@subversion.tigris.org (from
> kevin@tigris.org)
> cvs update: authorization failed: server cvs.tigris.org rejected access
> to /cvs for user kfogel
> cvs update: used empty password; try "cvs login" with a real password
>
> On Wed, Apr 18, 2001 at 02:24:36PM -0000, kevin@tigris.org wrote:
> > User: kevin
> > Date: 01/04/18 07:24:36
> >
> > Modified: notes multi-args.txt
> > Log:
> > Removed unnecessary assumption that no "../blah" paths exist in TL.
> >
> > Revision Changes Path
> > 1.4 +10 -9 subversion/notes/multi-args.txt
> >
> > Index: multi-args.txt
> > ===================================================================
> > RCS file: /cvs/subversion/notes/multi-args.txt,v
> > retrieving revision 1.3
> > retrieving revision 1.4
> > diff -u -r1.3 -r1.4
> > --- multi-args.txt 2001/04/17 21:56:28 1.3
> > +++ multi-args.txt 2001/04/18 14:24:36 1.4
> > @@ -23,22 +23,23 @@
> > How do we do this?
> >
> > Let TL be an apr_array_header_t representing the target list, in the
> > -order the targets appeared on the command line. Assume that no
> > -"../blah" paths are allowed in the targets.
> > +order the targets appeared on the command line.
> >
> > - 1. Remove redundancies from the target list: all targets that are
> > + 1. Convert each path in TL to an absolute path.
> > +
> > + 2. Remove redundancies from the target list: all targets that are
> > descendants of some other target are removed.
> >
> >
> > - 2. Find the longest common prefix ending with "/" for all the
> > + 3. Find the longest common prefix ending with "/" for all the
> > targets. Strip that prefix off all targets and save it for
> > later.
> >
> > - (Kevin Pilch-Bisson has written code to help with 1 and 2, see
> > - svn_path.c.)
> > + (Kevin Pilch-Bisson has written code to help with 1, 2 and 3, see
> > + libsvn_subr/target.c.)
> >
> >
> > - 3. Report the working copy state to the repository, to build a
> > + 4. Report the working copy state to the repository, to build a
> > transaction TXN that reflects the state of the working copy _as
> > necessary to update the requested targets_. For example:
> >
> > @@ -73,14 +74,14 @@
> > if the update won't affect it anyway.
> >
> >
> > - 4. Get an update editor, using the common prefix we saved earlier
> > + 5. Get an update editor, using the common prefix we saved earlier
> > as the path argument, and pass TL too.
> >
> > /* TODO: interface change to svn_wc_get_update_editor: Take
> > `apr_array_header_t *targets'. */
> >
> >
> > - 5. Drive the update editor:
> > + 6. Drive the update editor:
> >
> > a) Call set_target_revision (edit_baton);
> >
> >
> >
> >
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Kevin Pilch-Bisson http://www.pilch-bisson.net
> "Historically speaking, the presences of wheels in Unix
> has never precluded their reinvention." - Larry Wall
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Content-Type: application/pgp-signature
> Content-Disposition: inline
>
>
> This message contains data in an unrecognized format, application/pgp-signature,
> which is being decoded and written to the file named "/tmp/mm.D62978".
> If you do not want this data, you probably should delete that file.
> Wrote file /tmp/mm.D62978
Received on Sat Oct 21 14:36:29 2006