You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Lukas Reck <da...@gmail.com> on 2007/02/18 16:22:46 UTC
svn does not detect file recodings as changes
Hello
I recently had to recode some files under svn version control and I
had to go through some pains to commit the changes to the
repository...
Case in point:
lukas@hp-pv2000 ~/playground $ svnadmin create repo
lukas@hp-pv2000 ~/playground $ svn co file:///home/lukas/playground/repo wc
Checked out revision 0.
lukas@hp-pv2000 ~/playground $ echo -e '\xc3\xa9toile' > wc/testfile #
Some UTF-8 encoded text
lukas@hp-pv2000 ~/playground $ file wc/testfile # Verify the encoding
wc/testfile: UTF-8 Unicode text
lukas@hp-pv2000 ~/playground $ svn add wc/testfile && svn ci wc -m
'Added UTF-8 encoded test file'
A wc/testfile
Adding wc/testfile
Transmitting file data .
Committed revision 1.
lukas@hp-pv2000 ~/playground $ recode utf8..latin1 wc/testfile # now recode it
lukas@hp-pv2000 ~/playground $ file wc/testfile # Verify the encoding
wc/testfile: DOS executable (COM)
lukas@hp-pv2000 ~/playground $ svn status wc # the file has changed,
but svn does not see it!
lukas@hp-pv2000 ~/playground $ svn ci wc -m'Recoded testfile' # I
can't even check it in
lukas@hp-pv2000 ~/playground $ svn co
file:///home/lukas/playground/repo wc2 # And if I chack it out again
A wc2/testfile
Checked out revision 1.
lukas@hp-pv2000 ~/playground $ file wc2/testfile # it still is encoded in UTF-8
wc2/testfile: UTF-8 Unicode text
Seeing how svn's diff algorithm tries to be smarter than I am is
annoying. If this is a feature, the documentation should mention it,
and provide a workaround.
regards
Lukas Reck
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
svn does not detect file recodings as changes
Posted by Lukas Reck <da...@gmail.com>.
Hello,
I recently had to recode some files under svn version control and I
had to go through some pains to commit the changes to the
repository...
Case in point:
lukas@hp-pv2000 ~/playground $ svnadmin create repo
lukas@hp-pv2000 ~/playground $ svn co file:///home/lukas/playground/repo wc
Checked out revision 0.
lukas@hp-pv2000 ~/playground $ echo -e '\xc3\xa9toile' > wc/testfile #
Some UTF-8 encoded text
lukas@hp-pv2000 ~/playground $ file wc/testfile # Verify the encoding
wc/testfile: UTF-8 Unicode text
lukas@hp-pv2000 ~/playground $ svn add wc/testfile && svn ci wc -m
'Added UTF-8 encoded test file'
A wc/testfile
Adding wc/testfile
Transmitting file data .
Committed revision 1.
lukas@hp-pv2000 ~/playground $ recode utf8..latin1 wc/testfile # now recode it
lukas@hp-pv2000 ~/playground $ file wc/testfile # Verify the encoding
wc/testfile: DOS executable (COM)
lukas@hp-pv2000 ~/playground $ svn status wc # the file has changed,
but svn does not see it!
lukas@hp-pv2000 ~/playground $ svn ci wc -m'Recoded testfile' # I
can't even check it in
lukas@hp-pv2000 ~/playground $ svn co
file:///home/lukas/playground/repo wc2 # And if I chack it out again
A wc2/testfile
Checked out revision 1.
lukas@hp-pv2000 ~/playground $ file wc2/testfile # it still is encoded in UTF-8
wc2/testfile: UTF-8 Unicode text
Seeing how svn's diff algorithm tries to be smarter than I am is
annoying. If this is a feature, the documentation should mention it,
and provide a workaround.
regards
Lukas Reck
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn does not detect file recodings as changes
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2007-02-19 14:48:01 +0100, Lukas Reck wrote:
> So what is the rationale for not using max(mtime,cime) on POSIX(ish?)
> systems instead of the mtime? And even if there is one, why is this
> not documented?
I didn't have the answer to these questions. It seems that some
Subversion developers wanted to fix the problem on a highly broken
OS and didn't mind about POSIX systems (why not accepting the POSIX
behavior while Windows does much worse?).
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn does not detect file recodings as changes
Posted by Les Mikesell <le...@gmail.com>.
Duncan Murdoch wrote:
>>> So what is the rationale for not using max(mtime,cime) on POSIX(ish?)
>>> systems instead of the mtime? And even if there is one, why is this
>>> not documented?
>>
>> Ctime can never be less than mtime on anything resembling posix behavior.
>
> That's not right, is it? What if I use touch to set the modification
> time into the future? I see this on a Linux system:
>
> $ touch -t 06010000 junk
>
> $ ls -l junk
> -rw-r--r-- 1 murdoch murdoch 3 Jun 1 2007 junk
>
> $ ls -l --time=ctime junk
> -rw-r--r-- 1 murdoch murdoch 3 Feb 19 13:04 junk
>
> Does posix disallow this?
Yes, I said it wrong. Ctime can never be older than the time mtime was
last changed (because changing mtime is an inode change that will result
in ctime being updated to the current time). I didn't consider the case
where the value of mtime was artificially set in the future, but that
doesn't affect the case here where something is setting mtime back to
its prior value after a change.
> And a guess as to the rationale for this behaviour: svn uses mtime, so
> that a user can mess with it in order to change svn's behaviour. If a
> user does this accidentally (e.g. by using recode and not realizing that
> it doesn't update mtime) that's bad, but if svn used ctime then the user
> would not be able to control things.
If that was the intent, it doesn't see to have satisfied anyone. I don't
see any arguments here suggesting that this undocumented behavior is a
good thing. CVS didn't have any equivalent mechanism and I can't recall
anyone ever wanting a way to tell it to pretend a modified file wasn't
modified in a decade of use.
> I agree with whoever suggested that it would be nice to be able to tell
> svn to use a stricter criterion, e.g. a full binary compare on each file.
Yes, or make that the default with a way to tell it to do the
optimization based on timestamps.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn does not detect file recodings as changes
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2007-02-20 07:54:58 -0600, Les Mikesell wrote:
> I think what people are requesting is a _option_ to force a correct
> determination of 'changedness' to cover the situations where the
> timestamp can't be trusted. As a historical precedent, you might
> consider the 'rsync' program which needs to make approximately the same
> determination and thus the same need for an option to do it the fast or
> the correct way - and note that it does have exactly such an option.
But rsync is different as it doesn't make sense to compare the ctime
for remote files. So, with rsync, not using the mtime would really
make things slower, contrary to Subversion. Hence the option.
With Subversion, the option would be useful only for users who want
to set the mtime to some value so that Subversion doesn't regard the
file as modified. I don't think such a feature would be a good idea,
though.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
svnadmin hotcopy - format file not found
Posted by Robert Staflin <ro...@staflin.com>.
Can anyone give me a hint as to why my
"svnadmin hotcopy c:\svn\wms-source e:\subversionbackup\vms-source
--clean-logs"
gives me:
"svnadmin: Can't open the file "C:\svn\wms-source\format": The
search path cannot be found"
I have two different repositories in the c:\svn directory, and the
other one works fine. This command worked once, but hasn't since. The
format file is there, and has the same looks and properties in both
of the directories (the files contain a "5").
I can also use svnadmin to dump the repository, but I can't import it
afterwards - the same complaint is presented... Scary.
Please help? Should I consider using a Linux machine instead of
Windows XP for more consistent behavior?
Cheers,
/Robert Staflin
==================================================
KRS Consulting Robert Staflin
Stocksunds skola 503 B Tel: +46 (176) 236111
S-761 73 NORRTÄLJE Mobile: +46 (709) 582290
SWEDEN
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn does not detect file recodings as changes
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2007-02-20 13:46:00 +0100, Erik Huelsmann wrote:
> You'd rather wait for Subversion to read all of your entire 500MB
> working copy? You or your users will get insane.
Nonsense. Could you please read the thread?
> Subversion does and always will use the mtime as a heuristic for
> 'changedness' in its detection logic, until someone comes up with a
> faster way to do the same thing.
Yes, the proposed solution is as fast as the current solution and is
reliable.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn does not detect file recodings as changes
Posted by Jan Hendrik <ja...@myrealbox.com>.
Concerning Re: svn does not detect file recodi
Ryan Schmidt wrote on 25 Feb 2007, 4:09, at least in part:
> On Feb 23, 2007, at 02:29, Jan Hendrik wrote:
>
> > Ryan Schmidt wrote on 22 Feb 2007, 15:02, at least in part:
> >
> >> Jan: Duncan meant you should provide a set of commands that anyone
> >> could execute on their own machines to observe the problem. That
> >> means you should start with the creation of an empty repository,
> >> and go from there until you get the error. Like this script, which
> >> demonstrates the problem:
> >>
> >>
> >> # Create a new repo and check out a working copy
> >> $ svnadmin create repo
> >> $ svn co file://`pwd`/repo wc
> >> Checked out revision 0.
> >> $ cd wc
> >
> > [...]
> >
> > Thanks, Ryan, for this verbose example. As far as I can see you
> > fully translated my report, only that I should test it here of
> > course. Am I right in understanding that on *nix one would save this
> > into a file and run? I don't think it would work out at all on
> > Windows, that there usually isn't any "touch" or "ls" "cat" on
> > Windows or "dir" on *nix aside. Sorry, I may sound dense, but this
> > is absolutely new business to me.
>
> Some people provide shell scripts that can be run to demonstrate a
> problem. I'm wary of such scripts; I'd have to look into them myself
> to see what they do before I'd trust them enough to run them anyway.
> Myself, I like providing transcripts, including both the statements I
> ran (preceeded with "$"), comments about what I'm doing (preceeded
> with "#"), and the actual output of the commands. I think this way
> it's clear to someone just quickly reading the message what the
> output would be, without having to run it themselves.
>
> I don't use Windows so I don't know what you would have to do to
> reproduce the problem on that platform.
Alright, after much delay on my side (related to the way
MyRealBox operates these days) the issue was just filed:
http://subversion.tigris.org/issues/show_bug.cgi?id=2746
JH
---------------------------------------
Freedom quote:
Our policy is simple:
We are not going to betray our friends,
reward the enemies of freedom,
or permit fear and retreat to become American policies. ...
None of the four wars in my lifetime
came about because we were too strong.
It is weakness ... that invites adventurous adversaries
to make mistaken judgments.
-- Ronald Reagan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn does not detect file recodings as changes
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Feb 23, 2007, at 02:29, Jan Hendrik wrote:
> Ryan Schmidt wrote on 22 Feb 2007, 15:02, at least in part:
>
>> Jan: Duncan meant you should provide a set of commands that anyone
>> could execute on their own machines to observe the problem. That
>> means you should start with the creation of an empty repository, and
>> go from there until you get the error. Like this script, which
>> demonstrates the problem:
>>
>>
>> # Create a new repo and check out a working copy
>> $ svnadmin create repo
>> $ svn co file://`pwd`/repo wc
>> Checked out revision 0.
>> $ cd wc
>
> [...]
>
> Thanks, Ryan, for this verbose example. As far as I can see you
> fully translated my report, only that I should test it here of course.
> Am I right in understanding that on *nix one would save this into a
> file and run? I don't think it would work out at all on Windows, that
> there usually isn't any "touch" or "ls" "cat" on Windows or "dir" on
> *nix aside. Sorry, I may sound dense, but this is absolutely new
> business to me.
Some people provide shell scripts that can be run to demonstrate a
problem. I'm wary of such scripts; I'd have to look into them myself
to see what they do before I'd trust them enough to run them anyway.
Myself, I like providing transcripts, including both the statements I
ran (preceeded with "$"), comments about what I'm doing (preceeded
with "#"), and the actual output of the commands. I think this way
it's clear to someone just quickly reading the message what the
output would be, without having to run it themselves.
I don't use Windows so I don't know what you would have to do to
reproduce the problem on that platform.
--
To reply to the mailing list, please use your mailer's Reply To All
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn does not detect file recodings as changes
Posted by Jan Hendrik <ja...@myrealbox.com>.
Concerning Re: svn does not detect file recodings as changes
Ryan Schmidt wrote on 22 Feb 2007, 15:02, at least in part:
> Jan: Duncan meant you should provide a set of commands that anyone
> could execute on their own machines to observe the problem. That
> means you should start with the creation of an empty repository, and
> go from there until you get the error. Like this script, which
> demonstrates the problem:
>
>
> # Create a new repo and check out a working copy
> $ svnadmin create repo
> $ svn co file://`pwd`/repo wc
> Checked out revision 0.
> $ cd wc
[...]
Thanks, Ryan, for this verbose example. As far as I can see you
fully translated my report, only that I should test it here of course.
Am I right in understanding that on *nix one would save this into a
file and run? I don't think it would work out at all on Windows, that
there usually isn't any "touch" or "ls" "cat" on Windows or "dir" on
*nix aside. Sorry, I may sound dense, but this is absolutely new
business to me.
JH
---------------------------------------
Freedom quote:
Je weniger wirtschaftliche Freiheiten den Bürgern gewährt werden,
desto geringer sind der persönliche Wohlstand und der Wohlstand des ganzen Landes.
-- Patrick Welter,
Frankfurter Allgemeine Zeitung, 6. Jan. 2005
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn does not detect file recodings as changes
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Feb 21, 2007, at 10:52, Jan Hendrik wrote:
> Duncan Murdoch wrote on 20 Feb 2007, 10:05, at least in part:
>
>> On 2/20/2007 9:13 AM, Jan Hendrik wrote:
>
> [...]
>
>>> Anyway, the current SVN behaviour is in so far even worse as in a
>>> svn update any modification in such files is not merged, but
>>> overwritten - read: lost - as I just confirmed in a test, even if
>>> the filesize has changed by this "non-mtimed" modification. So IMHO
>>> SVN makes quite a dangerous guess by exclusively relying on mtime
>>> even in cases where modifications are not only just not committed,
>>> but could be written over.
>>
>> I'd call this a bug. You should put together a demo script and
>> submit
>> a bug report.
>>
>> It's arguable whether to use mtime or ctime or a full binary compare,
>> but to ignore changes in file size before a destructive update is
>> clearly a bug.
>
> Not being used to software development and bug reporting I'm not
> sure if this is the right way as suggested by you, but this is what
> I did:
Jan: Duncan meant you should provide a set of commands that anyone
could execute on their own machines to observe the problem. That
means you should start with the creation of an empty repository, and
go from there until you get the error. Like this script, which
demonstrates the problem:
# Create a new repo and check out a working copy
$ svnadmin create repo
$ svn co file://`pwd`/repo wc
Checked out revision 0.
$ cd wc
# Create a file that's modified at noon today
$ echo hello > foo.txt
$ touch -m -t 200702221200 foo.txt
$ ls -l
total 8
-rw-r--r-- 1 rschmidt wheel 6 Feb 22 12:00 foo.txt
# Note: file is 6 bytes
# Add and commit it
$ svn add foo.txt
A foo.txt
$ svn ci -m ""
Adding foo.txt
Transmitting file data .
Committed revision 1.
# Now change the file contents but keep mod time the same
$ echo goodbye > foo.txt
$ touch -m -t 200702221200 foo.txt
$ ls -l
total 8
-rw-r--r-- 1 rschmidt wheel 8 Feb 22 12:00 foo.txt
# Note: file is clearly different because it's now 8 bytes
$ svn st
# Note: svn st doesn't show that anything has changed
# Note: wc now contains changes, though svn doesn't think it does
# Now check out a new working copy and commit changes
$ cd ..
$ svn co file://`pwd`/repo wc2
A wc2/foo.txt
Checked out revision 1.
$ cd wc2
$ echo hi > foo.txt
$ svn ci -m ""
Sending foo.txt
Transmitting file data .
Committed revision 2.
# Go back into the first working copy with its stealth changes
$ cd ../wc
# See that our changed text is still there
$ cat foo.txt
goodbye
# Update
$ svn up
U foo.txt
Updated to revision 2.
# And now our changes are lost, with no notice from svn
# that this has happened -- no conflict, no merge, nothing
$ cat foo.txt
hi
$
Now all you have to do is file a bug report [1] and link to this
email [2].
[1] http://subversion.tigris.org/project_issues.html
[2] find it on http://svn.haxx.se/users/
--
To reply to the mailing list, please use your mailer's Reply To All
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn does not detect file recodings as changes
Posted by Jan Hendrik <ja...@myrealbox.com>.
Concerning Re: svn does not detect file recodi
Duncan Murdoch wrote on 20 Feb 2007, 10:05, at least in part:
> On 2/20/2007 9:13 AM, Jan Hendrik wrote:
[...]
> > Anyway, the current SVN behaviour is in so far even worse as in a
> > svn update any modification in such files is not merged, but
> > overwritten - read: lost - as I just confirmed in a test, even if
> > the filesize has changed by this "non-mtimed" modification. So IMHO
> > SVN makes quite a dangerous guess by exclusively relying on mtime
> > even in cases where modifications are not only just not committed,
> > but could be written over.
>
> I'd call this a bug. You should put together a demo script and submit
> a bug report.
>
> It's arguable whether to use mtime or ctime or a full binary compare,
> but to ignore changes in file size before a destructive update is
> clearly a bug.
Not being used to software development and bug reporting I'm not
sure if this is the right way as suggested by you, but this is what I did:
WC A on \\PC1:
svn update \\PC1\d\wc => rev. 1857 = HEAD
\\PC1\d\wc\foo.php (7,847 bytes, Aug. 9, 2006 21:49:00)
\\PC1\d\wc\bar.php (7,685 bytes, Aug. 9, 2006 21:49:00)
edit foo.php & bar.php
save both, touch timestamps => Aug. 9, 2006 21:49:00
new filesizes:
\\PC1\d\wc\foo.php : 7,847 bytes (unintentionally, but welcome)
\\PC1\d\wc\bar.php : 7,744 bytes
svn status \\PC1\d\wc (no modifications reported)
-------------------------
WC B on \\PC2:
svn update \\PC1\d\wc => rev. 1857 = HEAD
edit:
\\PC2\d\wc\foo.php (7,831 bytes)
\\PC2\d\wc\bar.php (7,726 bytes)
svn commit \\PC2\d\wc\ (both files committed, HEAD now 1858)
------------------------
WC A on \\PC1:
svn update =>
\\PC1\d\wc\foo.php & \\PC1\d\wc\bar.php updated to rev 1858
(HEAD)
filesizes 7,831 and 7,726 bytes resp. as committed in WC B,
timestamp Feb 20, 2007 16:33:36 (commit time)
modifications lost in both files, no merge has happened
For greater clarity I used UNC path, actually I worked locally on the
respective machines where the path is d:\wc\ on both.
I have repeated tests on several files in several directories during a
couple of days, first still with SVN 1.4.2, then upgraded to current
1.4.3 for confirmation.
System:
Win2K SP4 SRP1
NTFS filesystem
SVN 1.4.3 (same with 1.4.2)
BDB repository (created with SVN 1.4.2, dump/load cyclus)
HTH.
JH
---------------------------------------
Freedom quote:
... the question becomes,
are you going to have everyone play by the same rules,
or are you going to try to rectify the shortcomings,
errors and failures of the entire cosmos?
Because those things are wholly incompatible.
If you're going to have people play by the same rules,
that can be enforced with a minimum amount
of interference with people's freedom.
But if you're going to try to make the entire cosmos right and just,
somebody has got to have an awful lot of power
to impose what they think is right on an awful lot of other people.
What we've seen, particularly in the 20th century,
is that putting that much power in anyone's hands is enormously dangerous.
-- Thomas Sowell, 1999
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn does not detect file recodings as changes
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On 2/20/2007 9:13 AM, Jan Hendrik wrote:
> Concerning Re: svn does not detect file recodi
> Les Mikesell wrote on 20 Feb 2007, 7:54, at least in part:
>
>> I think what people are requesting is a _option_ to force a correct
>> determination of 'changedness' to cover the situations where the
>> timestamp can't be trusted. As a historical precedent, you might
>> consider the 'rsync' program which needs to make approximately the
>> same determination and thus the same need for an option to do it the
>> fast or
>> the correct way - and note that it does have exactly such an option.
>
> To me it looks this time issue can have much more practical and
> frequent reasons than the occasional deliberate resetting of mtime
> for special cases during FTP synching I have happening here.
>
> Anyway, the current SVN behaviour is in so far even worse as in a
> svn update any modification in such files is not merged, but
> overwritten - read: lost - as I just confirmed in a test, even if the
> filesize has changed by this "non-mtimed" modification. So IMHO
> SVN makes quite a dangerous guess by exclusively relying on
> mtime even in cases where modifications are not only just not
> committed, but could be written over.
I'd call this a bug. You should put together a demo script and submit a
bug report.
It's arguable whether to use mtime or ctime or a full binary compare,
but to ignore changes in file size before a destructive update is
clearly a bug.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn does not detect file recodings as changes
Posted by Jan Hendrik <ja...@myrealbox.com>.
Concerning Re: svn does not detect file recodi
Les Mikesell wrote on 20 Feb 2007, 7:54, at least in part:
> I think what people are requesting is a _option_ to force a correct
> determination of 'changedness' to cover the situations where the
> timestamp can't be trusted. As a historical precedent, you might
> consider the 'rsync' program which needs to make approximately the
> same determination and thus the same need for an option to do it the
> fast or
> the correct way - and note that it does have exactly such an option.
To me it looks this time issue can have much more practical and
frequent reasons than the occasional deliberate resetting of mtime
for special cases during FTP synching I have happening here.
Anyway, the current SVN behaviour is in so far even worse as in a
svn update any modification in such files is not merged, but
overwritten - read: lost - as I just confirmed in a test, even if the
filesize has changed by this "non-mtimed" modification. So IMHO
SVN makes quite a dangerous guess by exclusively relying on
mtime even in cases where modifications are not only just not
committed, but could be written over.
JH
---------------------------------------
Freedom quote:
It's time we asked ourselves if we still know the freedoms
intended for us by the Founding Fathers. James Madison said,
'We base all our experiments on the capacity of mankind for self-government.'
This idea that government was beholden to the people,
that it had no other source of power, is still the newest,
most unique idea in all the long history of man's relation to man.
This is the issue of this election:
Whether we believe in our capacity for self-government
or whether we abandon the American Revolution and confess
that a little intellectual elite in a far-distant capital
can plan our lives for us better than we can plan them ourselves.
-- Ronald Reagan, October 27, 1964
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn does not detect file recodings as changes
Posted by Les Mikesell <le...@gmail.com>.
Erik Huelsmann wrote:
> On 2/20/07, Vincent Lefevre <vi...@vinc17.org> wrote:
>> No. "recode" behaves as documented, not "svn". And even if it is
>> documented, it is still a very bad behavior as there are other
>> (say, more valid) ways to get the same mtime while the contents
>> are different. Programs whose behavior is based on timestamps
>> are bad (this is the case for "make", for historical reasons,
>> but Subversion is rather new and shouldn't go this way).
>
> You'd rather wait for Subversion to read all of your entire 500MB
> working copy? You or your users will get insane.
>
> Subversion does and always will use the mtime as a heuristic for
> 'changedness' in its detection logic, until someone comes up with a
> faster way to do the same thing.
I think what people are requesting is a _option_ to force a correct
determination of 'changedness' to cover the situations where the
timestamp can't be trusted. As a historical precedent, you might
consider the 'rsync' program which needs to make approximately the same
determination and thus the same need for an option to do it the fast or
the correct way - and note that it does have exactly such an option.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn does not detect file recodings as changes
Posted by Erik Huelsmann <eh...@gmail.com>.
On 2/20/07, Vincent Lefevre <vi...@vinc17.org> wrote:
> On 2007-02-19 15:08:55 -0500, Phillip Susi wrote:
> > This is an error in the recode utility, not svn.
>
> No. "recode" behaves as documented, not "svn". And even if it is
> documented, it is still a very bad behavior as there are other
> (say, more valid) ways to get the same mtime while the contents
> are different. Programs whose behavior is based on timestamps
> are bad (this is the case for "make", for historical reasons,
> but Subversion is rather new and shouldn't go this way).
You'd rather wait for Subversion to read all of your entire 500MB
working copy? You or your users will get insane.
Subversion does and always will use the mtime as a heuristic for
'changedness' in its detection logic, until someone comes up with a
faster way to do the same thing.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn does not detect file recodings as changes
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2007-02-19 15:08:55 -0500, Phillip Susi wrote:
> This is an error in the recode utility, not svn.
No. "recode" behaves as documented, not "svn". And even if it is
documented, it is still a very bad behavior as there are other
(say, more valid) ways to get the same mtime while the contents
are different. Programs whose behavior is based on timestamps
are bad (this is the case for "make", for historical reasons,
but Subversion is rather new and shouldn't go this way).
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn does not detect file recodings as changes
Posted by Les Mikesell <le...@gmail.com>.
Phillip Susi wrote:
>> Comparing the ctime would be more appropriate to determine if a file
>> has been meddled with since the last update, wouldn't it?
>
> No, it would not. The ctime is updated when the inode is modified, not
> when the file's contents are changed. That means whenever you change
> owner or permissions. The only reason ctime entered this discussion is
> because it gets updated when you manually change the mtime ( to put it
> back to where it was before you did modify the file ).
It is also updated in the more typical situation where mtime is updated
for the normal reason of having modified the file, so there is no down
side to using it to check for modifications.
> The entire point
> of not updating the mtime is to make it appear as though the file has
> not been changed, for instance, when you restore the file from a backup.
If you've restored from a backup you'd probably want svn to take the
extra fraction of a second to make sure things are actually correct.
> Trying to second guess a manually overridden mtime by looking at the
> ctime is not appropriate because it discards the user's wishes that they
> expressed by modifying the mtime.
You aren't trying to second guess the user since mtime wasn't manually
set directly by the user, and since ignoring modified files that happen
to have the same timestamp as before the modification isn't a documented
behavior of svn, it can't be what the user wants to happen. You are
second guessing the actions of another program second guessing the user.
> This is an error in the recode utility, not svn. Recode clearly
> modifies the file, so it should not be trying to hide that fact by
> reversing the mtime.
Until/unless svn documents the conditions under which modifications to
files under revision control are supposed to be ignored, it is a bug in svn.
> If recode doesn't have a way to disable this behavior, then an easy
> workaround would be to touch the file when you recode.
Yes, that should work.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn does not detect file recodings as changes
Posted by Phillip Susi <ps...@cfl.rr.com>.
Lukas Reck wrote:
> Comparing the ctime would be more appropriate to determine if a file
> has been meddled with since the last update, wouldn't it?
No, it would not. The ctime is updated when the inode is modified, not
when the file's contents are changed. That means whenever you change
owner or permissions. The only reason ctime entered this discussion is
because it gets updated when you manually change the mtime ( to put it
back to where it was before you did modify the file ). The entire point
of not updating the mtime is to make it appear as though the file has
not been changed, for instance, when you restore the file from a backup.
Trying to second guess a manually overridden mtime by looking at the
ctime is not appropriate because it discards the user's wishes that they
expressed by modifying the mtime.
This is an error in the recode utility, not svn. Recode clearly
modifies the file, so it should not be trying to hide that fact by
reversing the mtime.
If recode doesn't have a way to disable this behavior, then an easy
workaround would be to touch the file when you recode.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn does not detect file recodings as changes
Posted by Lukas Reck <da...@gmail.com>.
I have filed a documentation bug at
<http://subversion.tigris.org/issues/show_bug.cgi?id=2719>.
--
Lukas Reck
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn does not detect file recodings as changes
Posted by Lukas Reck <da...@gmail.com>.
> > At
> > worst, using ctime instead of mtime will result in doing some more
> > binary compares.
>
> Unless the user really did want svn to ignore the change, in which case
> we'll get a commit that shouldn't have happened.
Then how is a user to know that he can control svn's behaviour like
this if svn's use of mtimes is not documented? Documenting the issue
(maybe even pointing out the problems with recode and friends) is all
I'd ask for. As far as I can see, the svnbook does not talk about it.
I might have missed something though.
--
Lukas Reck
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn does not detect file recodings as changes
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2007-02-19 13:50:22 -0500, Duncan Murdoch wrote:
> On 2/19/2007 1:29 PM, Lukas Reck wrote:
> >svn only uses the mtime comparison as a shortcut to avoid doing a
> >full binary compare on all files. I fail to see why users could
> >need to control that behaviour.
>
> Why would users want to modify a file but not change the mtime?
Several reasons:
* For recode, because the contents don't change semantically: in
practice, users view a file as a sequence of characters, not a
sequence of bytes. They probably want to keep the mtime because
they need a way to know when the contents (as a sequence of
characters) were changed last time, and they don't have another
field for that. However, Subversion should still report the diff.
If one day, Subversion has a way to deal with file encoding (e.g.
via a property svn:encoding), then it could have an option to
regard an encoding change as an unmodified file, but I doubt that
this would be useful anyway.
* For patch -T or -Z, because "make" rules are based on timestamps.
But also, though the contents change locally, they don't if you
compare them to the remote file (i.e. you can see diff/patch as
a way to transmit files cheaply).
* For mv (please don't say to use "svn mv", because one doesn't
necessarily want to keep the history and because the source file
is not necessarily a versioned file), because the contents don't
change if you compare them to the source file. Ditto for unzip,
gunzip, scp -p, and so on.
> Perhaps they want some programs to treat the file as if it is
> unmodified. How is svn to know whether it is one of those programs
> or not?
Because it is not documented, and probably not wanted by any user.
If such a feature is included in Subversion, then there must be an
option to control it (like with most commands).
> >If they change a file's contents (and thus update the ctime), they
> >normally want those changes to be commited.
>
> And if they change the file's contents, they normally update the mtime.
No, see above. And in general, in a file system, if two files have
the same timestamp, you cannot deduce that they are identical (in
particular due to the time resolution).
> We're talking about an abnormal case here, where a user has made a
> choice to change a file but not to appear to have changed it.
It is not necessarily a user choice. The mv behavior is required
by POSIX, for instance. What if you checkout two repositories at
the same time and move some files from a working copy to the other
one (and overwrite some files at this occasion)?
> >At worst, using ctime instead of mtime will result in doing some
> >more binary compares.
The old algorithm was using ctime and AFAIK, no-one complained on
this point. The change was done only because of Windows.
BTW, "svn export" still set the mtime to the commit time.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn does not detect file recodings as changes
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On 2/19/2007 1:29 PM, Lukas Reck wrote:
> 2007/2/19, Duncan Murdoch <mu...@stats.uwo.ca>:
>> On 2/19/2007 12:22 PM, Les Mikesell wrote:
>> > Lukas Reck wrote:
>> >> 2007/2/19, Vincent Lefevre <vi...@vinc17.org>:
>> >>> On 2007-02-19 06:28:21 +0100, Lukas Reck wrote:
>> >>> > So as I understand it, it is not exactly svn's fault, but recode
>> >>> > messing with mtime.
>> >>>
>> >>> It's both. But I'd say that it's more svn's fault since changing the
>> >>> mtime is not forbidden and there may be good reasons to change it.
>> >>> Only the ctime can't be changed by the user and can be regarded as
>> >>> reliable.
>> >>
>> >> So what is the rationale for not using max(mtime,cime) on POSIX(ish?)
>> >> systems instead of the mtime? And even if there is one, why is this
>> >> not documented?
>> >
>> > Ctime can never be less than mtime on anything resembling posix behavior.
>>
>> That's not right, is it? What if I use touch to set the modification
>> time into the future? I see this on a Linux system:
>>
>> $ touch -t 06010000 junk
>>
>> $ ls -l junk
>> -rw-r--r-- 1 murdoch murdoch 3 Jun 1 2007 junk
>>
>> $ ls -l --time=ctime junk
>> -rw-r--r-- 1 murdoch murdoch 3 Feb 19 13:04 junk
>>
>> Does posix disallow this?
>>
>> And a guess as to the rationale for this behaviour: svn uses mtime, so
>> that a user can mess with it in order to change svn's behaviour. If a
>> user does this accidentally (e.g. by using recode and not realizing that
>> it doesn't update mtime) that's bad, but if svn used ctime then the user
>> would not be able to control things.
>
> svn only uses the mtime comparison as a shortcut to avoid doing a full
> binary compare on all files. I fail to see why users could need to
> control that behaviour.
Why would users want to modify a file but not change the mtime? Perhaps
they want some programs to treat the file as if it is unmodified. How
is svn to know whether it is one of those programs or not?
If they change a file's contents (and thus
> update the ctime), they normally want those changes to be commited.
And if they change the file's contents, they normally update the mtime.
We're talking about an abnormal case here, where a user has made a
choice to change a file but not to appear to have changed it.
> At
> worst, using ctime instead of mtime will result in doing some more
> binary compares.
Unless the user really did want svn to ignore the change, in which case
we'll get a commit that shouldn't have happened.
> Comparing the ctime would be more appropriate to determine if a file
> has been meddled with since the last update, wouldn't it?
Changing mtime is usually appropriate when meddling.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn does not detect file recodings as changes
Posted by Lukas Reck <da...@gmail.com>.
2007/2/19, Duncan Murdoch <mu...@stats.uwo.ca>:
> On 2/19/2007 12:22 PM, Les Mikesell wrote:
> > Lukas Reck wrote:
> >> 2007/2/19, Vincent Lefevre <vi...@vinc17.org>:
> >>> On 2007-02-19 06:28:21 +0100, Lukas Reck wrote:
> >>> > So as I understand it, it is not exactly svn's fault, but recode
> >>> > messing with mtime.
> >>>
> >>> It's both. But I'd say that it's more svn's fault since changing the
> >>> mtime is not forbidden and there may be good reasons to change it.
> >>> Only the ctime can't be changed by the user and can be regarded as
> >>> reliable.
> >>
> >> So what is the rationale for not using max(mtime,cime) on POSIX(ish?)
> >> systems instead of the mtime? And even if there is one, why is this
> >> not documented?
> >
> > Ctime can never be less than mtime on anything resembling posix behavior.
>
> That's not right, is it? What if I use touch to set the modification
> time into the future? I see this on a Linux system:
>
> $ touch -t 06010000 junk
>
> $ ls -l junk
> -rw-r--r-- 1 murdoch murdoch 3 Jun 1 2007 junk
>
> $ ls -l --time=ctime junk
> -rw-r--r-- 1 murdoch murdoch 3 Feb 19 13:04 junk
>
> Does posix disallow this?
>
> And a guess as to the rationale for this behaviour: svn uses mtime, so
> that a user can mess with it in order to change svn's behaviour. If a
> user does this accidentally (e.g. by using recode and not realizing that
> it doesn't update mtime) that's bad, but if svn used ctime then the user
> would not be able to control things.
svn only uses the mtime comparison as a shortcut to avoid doing a full
binary compare on all files. I fail to see why users could need to
control that behaviour. If they change a file's contents (and thus
update the ctime), they normally want those changes to be commited. At
worst, using ctime instead of mtime will result in doing some more
binary compares.
Comparing the ctime would be more appropriate to determine if a file
has been meddled with since the last update, wouldn't it?
--
Lukas Reck
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn does not detect file recodings as changes
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On 2/19/2007 12:22 PM, Les Mikesell wrote:
> Lukas Reck wrote:
>> 2007/2/19, Vincent Lefevre <vi...@vinc17.org>:
>>> On 2007-02-19 06:28:21 +0100, Lukas Reck wrote:
>>> > So as I understand it, it is not exactly svn's fault, but recode
>>> > messing with mtime.
>>>
>>> It's both. But I'd say that it's more svn's fault since changing the
>>> mtime is not forbidden and there may be good reasons to change it.
>>> Only the ctime can't be changed by the user and can be regarded as
>>> reliable.
>>
>> So what is the rationale for not using max(mtime,cime) on POSIX(ish?)
>> systems instead of the mtime? And even if there is one, why is this
>> not documented?
>
> Ctime can never be less than mtime on anything resembling posix behavior.
That's not right, is it? What if I use touch to set the modification
time into the future? I see this on a Linux system:
$ touch -t 06010000 junk
$ ls -l junk
-rw-r--r-- 1 murdoch murdoch 3 Jun 1 2007 junk
$ ls -l --time=ctime junk
-rw-r--r-- 1 murdoch murdoch 3 Feb 19 13:04 junk
Does posix disallow this?
And a guess as to the rationale for this behaviour: svn uses mtime, so
that a user can mess with it in order to change svn's behaviour. If a
user does this accidentally (e.g. by using recode and not realizing that
it doesn't update mtime) that's bad, but if svn used ctime then the user
would not be able to control things.
I agree with whoever suggested that it would be nice to be able to tell
svn to use a stricter criterion, e.g. a full binary compare on each file.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn does not detect file recodings as changes
Posted by Les Mikesell <le...@gmail.com>.
Lukas Reck wrote:
> 2007/2/19, Vincent Lefevre <vi...@vinc17.org>:
>> On 2007-02-19 06:28:21 +0100, Lukas Reck wrote:
>> > So as I understand it, it is not exactly svn's fault, but recode
>> > messing with mtime.
>>
>> It's both. But I'd say that it's more svn's fault since changing the
>> mtime is not forbidden and there may be good reasons to change it.
>> Only the ctime can't be changed by the user and can be regarded as
>> reliable.
>
> So what is the rationale for not using max(mtime,cime) on POSIX(ish?)
> systems instead of the mtime? And even if there is one, why is this
> not documented?
Ctime can never be less than mtime on anything resembling posix behavior.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn does not detect file recodings as changes
Posted by Lukas Reck <da...@gmail.com>.
2007/2/19, Vincent Lefevre <vi...@vinc17.org>:
> On 2007-02-19 06:28:21 +0100, Lukas Reck wrote:
> > So as I understand it, it is not exactly svn's fault, but recode
> > messing with mtime.
>
> It's both. But I'd say that it's more svn's fault since changing the
> mtime is not forbidden and there may be good reasons to change it.
> Only the ctime can't be changed by the user and can be regarded as
> reliable.
So what is the rationale for not using max(mtime,cime) on POSIX(ish?)
systems instead of the mtime? And even if there is one, why is this
not documented?
--
Regards, Lukas Reck
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn does not detect file recodings as changes
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2007-02-19 06:28:21 +0100, Lukas Reck wrote:
> So as I understand it, it is not exactly svn's fault, but recode
> messing with mtime.
It's both. But I'd say that it's more svn's fault since changing the
mtime is not forbidden and there may be good reasons to change it.
Only the ctime can't be changed by the user and can be regarded as
reliable.
> Still I think that the documentation should state explicitly that
> subversion looks at file mtimes before actually examining file
> contents, and warn about tools like recode (and mv, but I think
> you're supposed to svn mv anyway) that do not handle mtime
> according to svn's expectations.
There are cases where one may prefer mv (and when one must use mv).
There's also the "patch" command (with -T or -Z) for instance.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn does not detect file recodings as changes
Posted by Lukas Reck <da...@gmail.com>.
2007/2/19, Vincent Lefevre <vi...@vinc17.org>:
> On 2007-02-18 17:22:46 +0100, Lukas Reck wrote:
> > Seeing how svn's diff algorithm tries to be smarter than I am is
> > annoying. If this is a feature, the documentation should mention it,
> > and provide a workaround.
>
> This is due to the fact that by default, recode doesn't modify the
> mtime (this is a feature). I reported the problem last year, in the
> dev mailing-list:
>
> http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=117800
>
> It is annoying that Subversion developers don't regard it as a bug,
> even though there would be a simple fix: look at ctime too (under
> Unix).
So as I understand it, it is not exactly svn's fault, but recode
messing with mtime. Still I think that the documentation should state
explicitly that subversion looks at file mtimes before actually
examining file contents, and warn about tools like recode (and mv, but
I think you're supposed to svn mv anyway) that do not handle mtime
according to svn's expectations.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn does not detect file recodings as changes
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2007-02-18 17:22:46 +0100, Lukas Reck wrote:
> Seeing how svn's diff algorithm tries to be smarter than I am is
> annoying. If this is a feature, the documentation should mention it,
> and provide a workaround.
This is due to the fact that by default, recode doesn't modify the
mtime (this is a feature). I reported the problem last year, in the
dev mailing-list:
http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=117800
It is annoying that Subversion developers don't regard it as a bug,
even though there would be a simple fix: look at ctime too (under
Unix).
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org