no out-of-date error

[Subversion <Su...@sensor-technik.de>]

Hello all

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.

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.

Regards

Christoph




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: no out-of-date error

[Ryan Schmidt <su...@ryandesign.com>]

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