On Mar 29, 2006, at 17:16, Subversion wrote:
> Can anyone tell me when *exactly* an out-of-date error shall
> happen. I'm a little bit confused right now, because I did some
> tests with 2 working copies of the same repository.
I think it happens exactly when you have a working copy and try to
commit a change to a file or directory that has been changed by
someone else since the time you updated that item. Adding or deleting
a file causes its parent directory to be "modified" according to
Subversion.
> Lets say their names are "foo1" and "foo2" and their are checked
> out from the repository "repo" in revision 10.
>
> Within the working copies there are subfolders and source files. If
> now user Harry is changing a file within foo1 (maybe bar1.c) and
> user Sally is changing another file in foo2 (let's say bar2.c),
> both working copies have now unversioned changes in different files.
> If now Harry does an Commit to repo, changes of bar1.c are
> committed to repo and the revision number increases to 11.
>
> I expect now, that Sally gets an out-of-date error if she tries to
> commit the changes of bar2.c to the repository, because her Base
> revision is no longer the Head revision of the repository.
>
> But this doesn't happen. Instead, the changes of bar2.c are
> committed to the repository in revision 12 and Sally doesn't get
> notified about the changes in bar1.c.
>
> Only if the changes are in the same file, subversion comes back
> with an out-of-date error.
>
> Can anyone tell me if this behaviour is intended or if it has been
> fixed or will be fixed in a newer version.
The behavior is intended. The item Sally is committing, bar2.c, is
not out of date; it's exactly up-to-date with the HEAD of the
repository. Thus there is no error.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Mar 29 18:29:31 2006