The svn test repo has been updated on dberlin.org.
Please don't rape my bandwidth or my disk i/o :)
svn://www.dberlin.org/
Commits to the hooks dir will be reflected in the actual repository
hooks through the nice sync script.
If people help convert the contrib scripts and the current cvs
repos
I can only guess the outcry if Perl started obeying LC_COLLATE.
What do you mean, "started"? It's been doing that for years now.
By default, Perl ignores the current locale. The "use locale" pragma
tells Perl to use the current locale for some operations:
and these do not include regex chara
On 2005-02-17 20:29:00 +0200, Kai Henningsen wrote:
> [EMAIL PROTECTED] (Paolo Bonzini) wrote on 17.02.05 in <[EMAIL PROTECTED]>:
> > I can only guess the outcry if Perl started obeying LC_COLLATE.
>
> What do you mean, "started"? It's been doing that for years now.
Not by default. From the per
[EMAIL PROTECTED] (Paolo Bonzini) wrote on 17.02.05 in <[EMAIL PROTECTED]>:
> > The sort alghorithm has nothing to do with ls, but with your selection of
> > LC_COLLATE. But then, BSD (at least the variant used in MacOSX) is way
> > behind current l10n standards.
>
> At least they do not break s
On Thu, 2005-02-17 at 12:48 +0100, Marc Espie wrote:
> In article <[EMAIL PROTECTED]> you write:
> >AFAIK, Subversion uses UTC time internally, but always works with the
> >local time of the user for the interface (I don't know what happens for
> >ambiguous dates, due to summer/winter times). Anywa
On 2005-02-17 12:48:03 +0100, Marc Espie wrote:
> Bottom-line: it's very easy to shoot oneself in the foot while writing
> wrapper scripts. The default interface will give you local time listing,
> anything you generate from that will have localtime listing, so any
> `nice' meta-generated informat
The sort alghorithm has nothing to do with ls, but with your selection of
LC_COLLATE. But then, BSD (at least the variant used in MacOSX) is way
behind current l10n standards.
At least they do not break s/[A-Z]// which on "well-internationalized"
OSes is case-insensitive with most locales other t
In article <[EMAIL PROTECTED]> you write:
>AFAIK, Subversion uses UTC time internally, but always works with the
>local time of the user for the interface (I don't know what happens for
>ambiguous dates, due to summer/winter times). Anyway, Subversion has
>global revisions, so that doing a dichotom
On 2005-02-17 01:48:37 +0100, Marc Espie wrote:
> Dare I say it ?
> I don't want any locale behavior in a version control system.
> Specifically because there are client/server issues, and you never
> know which is which. I've seen enough trouble with cvs timestamps.
>
> If/when gcc switches to s
In article <[EMAIL PROTECTED]> you write:
>Complete alphabetical order is not in the cards for diff, at least for
>diffs involving server side (diffs that are client side are easily
>sorted by filename).
>This is because it would require losing the "streaminess" of the
>protocol (unlike cvs, the cl
Daniel Berlin wrote:
You assume the tree walker ever sees an entire directory at once, for
starters.
It seems a reasonable assumption that such a tree walker exists or
could be written without too much pain. I can imagine a tree walker
that iterates over file numbers (a la inodes), and that may be
Andreas Schwab wrote:
Per Bothner <[EMAIL PROTECTED]> writes:
Preferably, the sort algorithm should match 'ls'. (Specifically
GNU ls - IIRC BSD ls doesn't case-fold, which I think is wrong.
The sort alghorithm has nothing to do with ls, but with your selection of
LC_COLLATE.
If we're going to ni
Per Bothner <[EMAIL PROTECTED]> writes:
> Preferably, the sort algorithm should match 'ls'. (Specifically
> GNU ls - IIRC BSD ls doesn't case-fold, which I think is wrong.
The sort alghorithm has nothing to do with ls, but with your selection of
LC_COLLATE. But then, BSD (at least the variant u
On Wed, 2005-02-16 at 09:41 -0800, Per Bothner wrote:
> Daniel Berlin wrote:
> Huh? I don't get this. You sort filenames *in* the server *before*
> you generate diffs. And you do the sorting within each directory;
> i.e. early before you do anything else. What does the "streaming
> protocol" ha
On 2005-02-16 09:41:13 -0800, Per Bothner wrote:
> Preferably, the sort algorithm should match 'ls'.
FYI, the way ls (from the coreutils) sorts the filenames is
locale-dependent. :(
> No problem. The client's request can include the current LOCALE value.
> However, I'm not sure that's derirable.
Daniel Berlin wrote:
Complete alphabetical order is not in the cards for diff, at least for
diffs involving server side (diffs that are client side are easily
sorted by filename).
This is because it would require losing the "streaminess" of the
protocol (unlike cvs, the client and the server in svn
On Wed, Feb 16, 2005 at 02:43:35PM +, Joseph S. Myers wrote:
> On Tue, 15 Feb 2005, Daniel Berlin wrote:
>
> > However, if you are satisfied with client-only diff (which is the main
> > case when you'd be writing changelogs) working in alphabetical order, i
> > should be able to wing that.
>
On Tue, 15 Feb 2005, Daniel Berlin wrote:
> However, if you are satisfied with client-only diff (which is the main
> case when you'd be writing changelogs) working in alphabetical order, i
> should be able to wing that.
Client-only diff is the main case. (For more general cases it should be
pos
On Tue, 2005-02-15 at 03:09 +, Joseph S. Myers wrote:
> Another incidental observation from experiments with subversion: the
> output from svn diff seems to be in a fairly random order (rather than
> alphabetical order of filenames). Alphabetical order tends to be easier
> to follow when ch
Another incidental observation from experiments with subversion: the
output from svn diff seems to be in a fairly random order (rather than
alphabetical order of filenames). Alphabetical order tends to be easier
to follow when checking svn diff output to see that the changes you're
about to co
On Mon, 2005-02-14 at 18:54 -0500, Daniel Berlin wrote:
> The SVN test repo has been updated. annotate should work at a reasonable
> speed (< 2 minutes for a file), *except* on the changelog. It spends a
> long time just groveling the file history. People who try to run
> annotate on the ChangeLog
The SVN test repo has been updated. annotate should work at a reasonable
speed (< 2 minutes for a file), *except* on the changelog. It spends a
long time just groveling the file history. People who try to run
annotate on the ChangeLog will be beaten severely.
I'm building a bdb test repo to see
22 matches
Mail list logo
