Peter Samuelson peter_at_p12n.org wrote:
Now do a 'svn update' or 'svn switch' which changes foo.c.
Current svn: foo.c mtime is set to the present time. It is now newer
than foo.o. [Of course you can set foo.o's mtime in the future, but
that's just breaking things _on purpose_.]
Ahem. At
-Original Message-
From: Fuhrmann Stefan (ETAS/ESA1) [mailto:stefan.fuhrm...@etas.com]
Sent: vrijdag 17 februari 2012 9:27
To: dev@subversion.apache.org
Cc: r...@longbowgames.com; pe...@p12n.org
Subject: Re: MTime resurrected
Peter Samuelson peter_at_p12n.org wrote:
Now do a
On 2012-02-17 4:34 AM, Bert Huijben wrote:
-Original Message-
From: Fuhrmann Stefan (ETAS/ESA1) [mailto:stefan.fuhrm...@etas.com]
Sent: vrijdag 17 februari 2012 9:27
To: dev@subversion.apache.org
Cc: r...@longbowgames.com; pe...@p12n.org
Subject: Re: MTime resurrected
Peter
Daniel Shahaf d...@daniel.shahaf.name writes:
danie...@tigris.org wrote on Thu, Feb 16, 2012 at 17:00:07 -0800:
--- Additional comments from danie...@tigris.org Thu Feb 16 17:00:07
-0800 2012 ---
% ln -s foo bar
% $svn add -q bar
% $svn cat bar
svn: E29:
Bert Huijben wrote:
Fuhrmann Stefan (ETAS/ESA1) wrote:
Peter Samuelson peter_at_p12n.org wrote:
Now do a 'svn update' or 'svn switch' which changes foo.c.
Current svn: foo.c mtime is set to the present time. It is now newer
than foo.o. [Of course you can set foo.o's mtime in the
Fuhrmann Stefan (ETAS/ESA1) stefan.fuhrm...@etas.com writes:
But since we already have an (optional) feature
that will use older timestamps, I don't see why
optionally preserving mtime would be too hard.
The only potential problems that came to my mind
were sync'ing the wc.db with mtime upon
On 2012-02-17 13:54:35 +0900, Hiroaki Nakamura wrote:
Actually, whether filename is in NFC or NFD depends on the way of
inputting filenames.
If you type all characters, it is in NFC.
No, or actually, perhaps this depends on the user configuration
(e.g. keyboard configuration / input method).
On 2012-02-17 6:41 AM, Fuhrmann Stefan (ETAS/ESA1) wrote:
I'm not championing the mtime feature but if
someone demonstrates a compelling use-case, it
should neither be hard nor risky to implement it.
-- Stefan^2.
There have been quite a lot of use cases presented over the years. A is
mine; B
On 2012-02-17 9:06 AM, Julian Foad wrote:
I wouldn't call that email a design worked out. My reply to that email posed
a load of questions and issues to be clarified or re-thought, and wasn't answered AFAICT.
Other people did the same and did get some more discussion in that thread, but
Rick Yorgason r...@longbowgames.com writes:
So if you add the option to treat mtime-only changes as modifications,
I definitely don't think it should be the default option. It's also
probably safe to leave that option out until some squeeky wheels speak
up.
It's not an option, it's an
I'm able to replicate this failure on my Windows box with my own
builds of trunk@1245285, 1.7.0 and 1.7.3. Alexey's script works as
expected with 1.6.17, so this appears to be a regression. Moving back
to the dev list.
Investigating...
Paul
On Thu, Feb 16, 2012 at 3:28 PM, C. Michael Pilato
Philip Martin philip.mar...@wandisco.com writes:
Paul Burba ptbu...@gmail.com writes:
I'm able to replicate this failure on my Windows box with my own
builds of trunk@1245285, 1.7.0 and 1.7.3. Alexey's script works as
expected with 1.6.17, so this appears to be a regression. Moving back
Rick Yorgason r...@longbowgames.com writes:
and I was picturing it as:
* Commit always sends the text-time.
* Updates only use the text-time if (a) it doesn't affect the current
workflow, or (b) the user explicitly asks for it.
I think the second option is safer, since it's easier to
Paul Burba ptbu...@gmail.com writes:
I'm able to replicate this failure on my Windows box with my own
builds of trunk@1245285, 1.7.0 and 1.7.3. Alexey's script works as
expected with 1.6.17, so this appears to be a regression. Moving back
to the dev list.
Investigating...
svn: E720005:
Philip Martin wrote on Fri, Feb 17, 2012 at 09:56:38 +:
Daniel Shahaf d...@daniel.shahaf.name writes:
danie...@tigris.org wrote on Thu, Feb 16, 2012 at 17:00:07 -0800:
--- Additional comments from danie...@tigris.org Thu Feb 16 17:00:07
-0800 2012 ---
% ln -s foo bar
%
On Fri, Feb 17, 2012 at 10:54 AM, Philip Martin
philip.mar...@wandisco.com wrote:
Paul Burba ptbu...@gmail.com writes:
I'm able to replicate this failure on my Windows box with my own
builds of trunk@1245285, 1.7.0 and 1.7.3. Alexey's script works as
expected with 1.6.17, so this appears to
Philip Martin philip.mar...@wandisco.com writes:
We have a new flag and a new mode, so the new behaviour can be almost
anything. Why is is acceptable to ignore mtime-only changes? It makes
no sense to me. It might be acceptable as an experiment but really it's
a half-baked solution.
Hyrum K Wright hyrum.wri...@wandisco.com writes:
On Fri, Feb 10, 2012 at 4:24 PM, Bert Huijben b...@qqmail.nl wrote:
-Original Message-
From: hwri...@apache.org [mailto:hwri...@apache.org]
Sent: vrijdag 10 februari 2012 23:11
To: comm...@subversion.apache.org
Subject: svn commit:
Could you fold this into the main code as an option? No one seems to talk
about some of the significant performance issues with SVN 1.7 much here.
For many people SVN 1.7 is still not an option due to these kinds of
performance issues. It seems like we need to revisit many the SQLite
operations
19 matches
Mail list logo
