> -----Original Message-----
> From: Ryan Schmidt [mailto:subversion-2011a_at_ryandesign.com]
> Sent: dinsdag 12 juli 2011 4:13
> To: Warren Jones
> Cc: users_at_subversion.apache.org
> Subject: Re: Perplexing results of SVN commit
>
> On Jul 11, 2011, at 14:07, Warren Jones wrote:
>
> > One of our developers got perplexing results from an SVN commit. As far
> as I can tell, this is what happened:
> >
> > 1. Developer checks out trunk of SVN project to working directory.
> > 2. "svn copy" some files from branch into working directory.
> > 3. Edit and modify files copied from branch.
> > 4. "svn commit" in working directory.
> >
> > After the commit:
> >
> > 1. "svn status" shows the working directory is up to date.
> > 2. "svn diff" shows no modified files in the working directory.
> > 3. Repository contains files copied from branch to trunk.
> > 4. Repository **does not** contain subsequent mods to those files.
The
> commit somehow missed these changes.
> > 5. File mods are still in the working directory, although not shown
by "svn
> diff".
> > 6. After file time stamps are updated with "touch", "svn diff" shows
> changes.
> >
> > I'm unable to reproduce this odd state of affairs, but I have the
repository
> and the developer's working directory to prove that something went wrong
> with the commit. I don't know whether it was operator error or a bug in
SVN.
>
> Sounds to me like operator error of the following kind: the developer
> modified the files in the working copy, and also made identical
modifications
> to the corresponding pristine files in .svn/text-base (frequently this
happens
> when using a batch search-replace tool). Because even after the edits the
> contents of the pristine files match the regular files, "svn st" and "svn
di"
> don't show the changes and they don't get committed.
>
> If this is what happened, check out a fresh working copy, manually copy
over
> the changed files, and commit them. And ensure that in the future you do
> not edit anything in the .svn directories. Some batch search-replace tools
let
> you define directories they're not to touch.
'svn status' only notices that files are modified if either the size or the
date changed since the last subversion operation that modified the file.
(Subversion automatically waits for some time to make sure other tools can't
change files in the same second when the filesystem has less than or exactly
1 second timestamp precision)
A clock skew between tool and filesystem might introduce this problem if you
have a script that updates files directly after update.
But personally I would guess that Ryan's answer is far more likely as
usually at least some file sizes change.
Bert
Received on 2011-07-12 11:55:19 CEST