Re: SVN repo updated, http access, and commit mail format

[Daniel Berlin <dberlin at dberlin dot org>]

On Tue, 2005-03-01 at 21:00 +0000, Joseph S. Myers wrote:
> On Tue, 1 Mar 2005, Daniel Berlin wrote:
> 
> > > Date: 2005-03-01 15:26:25 -0500 (Tue, 01 Mar 2005)
> 
> I take it the time will be shown in gcc.gnu.org's timezone (fixed at UTC), 
> not depending on the timezone of the person making the commit?

I believe this can be configured. 

> 
> > > WebSVN: http://dberlin.org/cgi-bin/viewcvs.cgi?
> > > view=rev&root=gccrepo&rev=77017
> > > 
> > > Modified:
> > >    trunk/gcc/ChangeLog
> > >    trunk/gcc/tree-ssa-alias.c
> > >    trunk/gcc/version.c
> > > 
> > > 
> > 
> > 
> > (The >'s are not in the message, obviously)
> 
> Does the message also have the URL on one line?  It ought to.

Yes, it does.
Evolution decided it would be cute to turn my paste into a word-wrapped
message.

> 
> > This seemed close to what we have now.  Note that the link included
> > above does work and will take you to the web page giving you the
> > differences.  Please don't browse the revision logs of files using
> > viewcvs. I don't have the network bandwidth on dberlin.org
> > 
> > Note that in the commit message, There is only need for one link,
> > because the revision view will display the entire changeset.
> 
> Can viewcvs be configured so that the links at the URL go to unidiffs by 
> default, as in the present URLs?  I find unidiffs much more readable than 
> coloured diffs.
Yes, it can be configured to do so.


> 
> What will the message / the diffs look like for changes to properties 
> rather than file contents?


Author:
Revision:
Property name:
Action: (added or modify or deleted)

<for added, Property value: new property value
 for modified, a unidiff of the old and new value.
 for deleted, nothing>

> 
> What will things (both the messages and the diffs) look like where files 
> or directories are copied (including copies of the whole tree, as for 
> tagging) or moved or copied-and-modified in one commit?

Just like they do for regular adds/deletes/modifications, except the
path names will be different.

Tagging just looks like a directory add with history.

...
Log:
Testing a branch merge in a second

Added:
   branches/testbranch/
      - copied from r77013, /trunk/



> I take it with SVN the messages to gcc-cvs-wwwdocs can work like the 
> gcc-cvs ones, i.e. including the URL for diffs? 
Yes.


>  That is, there won't be 
> any problems like those mentioned in comments in bugzilla-checkout and 
> htdocs-checkout and cgibin-checkout with the new scripts.

I don't understand what the real problem is, because the comments claim
something that is so strange to me i have a hard time believing it.
I can tell you you can run multiple scripts, and it will properly
substitute things, etc.
So in fact, it seems like the checkout scripts don't need to send mail
like they do now.
The mailer script can be told that mail for paths matching certain
regexps go include diffs in the mail, or go to different email lists.
Same with repos matching different regexps.


> Please ensure that the new script ends up version controlled,

All hooks will be version controlled, with a script to sync the version
controlled versions with the ones in the actual hooks dir of the repo.

>  whether in 
> maintainer-scripts in GCC SVN (maybe preferable) or in sourceware 
> infra/bin CVS.  I don't like the present situation where 
> log_accum_bugzillafied isn't version-controlled although its predecessor 
> was.

This is in part because i didn't have write access to the directory
containing the rcs version.