Re: svn commit: rev 47516 - spamassassin/trunk

[Justin Mason <jm...@jmason.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


mss@apache.org writes:
> Author: mss
> Date: Wed Sep 29 16:25:24 2004
> New Revision: 47516
> 
> Modified:
>    spamassassin/trunk/MANIFEST
>    spamassassin/trunk/MANIFEST.SKIP
> Log:
> Sort MANIFEST* alphabetically (again? maybe we should do this via a script)

actually, it's better *not* to do this.

  1. it makes merging the file a pain, if/when that becomes necessary

  2. someone else did it last time and used DIFFERENT sort semantics
     from yours (yours = case sensitive, theirs = case-i)!   The file
     was *already* sorted, just using case-i.

  3. the MANIFEST order dictates the order of files in the tarball,
     and in my opinion it's better to have the README, UPGRADE et al
     listed first.   (this isn't aimed at your sorting, it's aimed
     at whoever sorted it last time btw)

- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh CVS

iD8DBQFBW0joQTcbUG5Y7woRAhuGAJ96xyNwIfvltbXZqhsf8csXZ+464ACfSdP2
4AbVDQHKYaXlZsznMR1Zyp0=
=lJ/v
-----END PGP SIGNATURE-----

Re: svn commit: rev 47516 - spamassassin/trunk

["Malte S. Stretz" <ms...@gmx.net>]

On Thursday 30 September 2004 01:44 CET Justin Mason wrote:
> mss@apache.org writes:
> > Author: mss
> > Date: Wed Sep 29 16:25:24 2004
> > New Revision: 47516
> >
> > Modified:
> >    spamassassin/trunk/MANIFEST
> >    spamassassin/trunk/MANIFEST.SKIP
> > Log:
> > Sort MANIFEST* alphabetically (again? maybe we should do this via a
> > script)
>
> actually, it's better *not* to do this.
>
>   1. it makes merging the file a pain, if/when that becomes necessary

If the file is sorted in each branch, merging is no issue :~)  I'll do the 
same with the one in the branch so merging any possible changes is made 
easier again...

Why I sort that file now and then is because it makes it much easier to see 
if a file is already in there or remove one which is gone.  Keeping the 
MANIFEST up-to-date is already a PITA and an unsorted file makes it even 
worse (ok, there are grep and friends but I think its faster to scan the 
file with your eyes instead of calling some command).

It would be cool if subversion could be configured in a way that the file is 
piped through sort on each commit.  Even cooler would be if the server 
would check on each added or removed file if it is already in either the 
MANIFEST or MANIFEST.SKIP and print a warning in the commit message if not.  
Hmmm....

>   2. someone else did it last time and used DIFFERENT sort semantics
>      from yours (yours = case sensitive, theirs = case-i)!   The file
>      was *already* sorted, just using case-i.

Yeah, I noticed that too late.  I noticed that MANIFEST.SKIP wasnt sorted 
yet and just did a 'cat MANIFEST | sort' on both the files thinking that if 
the other wasn't sorted yet it wouldn't change anything...

>   3. the MANIFEST order dictates the order of files in the tarball,
>      and in my opinion it's better to have the README, UPGRADE et al
>      listed first.   (this isn't aimed at your sorting, it's aimed
>      at whoever sorted it last time btw)

I don't see the point in maintaining any order in the tarball -- everybody 
and -script I know either checks out the sources or does a 'tar xvfj' on 
the bzipped tarball;  neither the one nor the other cares about the order. 

But if the stuff is sorted case sensitive, the README and stuff should stay 
on top.

Cheers,
Malte

-- 
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
      <http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
      <http://www.catb.org/~esr/faqs/smart-questions.html>