Sometime earlier in this thread, it was written:
>
> > > I probably
>> > should be aware from the start that deliberately working on mtime
>> > might have unwanted side effects, an average user of a tool like
>> > recode has no good reason to expect issues with Subversion.
>>
>> > Of course it is impossible to prepare for any circumstance, but on
>> > one hand we constantly get told mtime is unreliable and useless
>> > while on the other hand Subversion just takes chances on this very
>> > mtime without taking into account any other parameter for making
>> > vital decisions. That's quite strange.
>>
>> Subversion is built on the assumption that mtime is unreliable, with
>> the exception that it expects mtime to have changed when the file has
>> changed. In an average work-cycle (and even in not-so-average work
>> cycles), that's a reasonable assumption. If the file has stayed the
>> same, there's no problem with the mtime being changed. Subversion
> > won't commit the file.
I just rejoined this list after a long absence, so I have no idea
what has been covered in this thread. However, one of the reasons I
rejoined is that I had thought I had stumbled upon some serious bug
in subversion. But after a little more investigation into my problem,
I realized what had happened:
I had a work area checked out, and needed to make the same change to
many files in the workarea. I used a 'find ... | xargs' command
to make the change. I compiled everything, and it worked. I did the
'svn commit', and that also worked fine. I made some other changes
and committed those. Later on, I made a change to one of the source
files changed by the find/xargs combo, and when I went to commit
*that* change, the 'svn commit' aborted with a message about
file-corruption in one of the .svn directories.
What apparently had happened was the find/xargs combo had changed
both the workarea source file, and the copy of it saved in the .svn
directory. Since both files were changed by a single unix command,
both copies of the file ended up with the same mtime. So at commit
time, 'svn' did not realize the file was changed and apparently
the change to that file was not committed when I thought it was.
Obviously typo in the find/xargs combo was my fault. And it's my
fault that I didn't notice that the 'svn commit' did not list some
files which had changed, and I guess I should have known they had
changed and noticed they weren't listed. (...but my excuse is that
the commit was changing more than fifty files, and I just didn't
bother to look over the entire list of files to notice if anything
was missing).
However, it was a little disconcerting that 'svn' did not notice there
was a problem until a *later* commit. If this was a normal repo in a
standard development cycle, I wonder how long it would have taken me
to figure out which commit had the real error. What if weeks had
passed between the screwed-up commit and the commit where 'svn'
finally noticed that things were screwed up?
It happens that I was building a new repo from a motley collection of
old patch files, and I figured the only safe way to do that was to
repeatedly re-create the entire repo from scratch until I was sure I
had all the patches applied in the right order. So I had a script
which started out by creating a brand new repo, and then applied each
of updates, and did the appropriate commits. Given that I could
easily re-create every commit the repository had ever seen, it was
pretty easy for me to figure out what had happened.
Once I realized that svn was making a decision based on mtime-checking,
I also changed my script to put a "sleep 1" between each commit, just to
make sure the mtime's were changing! And in fact my first few attempts
to run this script had hit other problems due to this mtime-checking,
but I had figured a way around those problems without understanding
what was causing them.
> > I'm sorry you feel disappointed and of course you're free to submit
>> patches which give Subversion better 'changedness' heuristics, but
>> please, make sure they don't come at an extra cost: Subversion isn't
> > very bareable for many windows users of corporate projects as it is...
I will admit that I don't know enough about the internals of svn to
even know what to suggest yet. I'm not even sure if I should file
this in the official bug-reporting database. I want to think about
it some more before I do that, but I thought I'd at least mention it
as long as mtime-checking seemed to be a topic for discussion here...
--
Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Mar 9 22:04:12 2007