I think I wasn't exact enough at the example. The problem is when I commit a folder in which I changed a file and a newer revision of that folder is in the repository because someone else committed another file to that directory, I doesn't get an out-of-date error.
Let's take the example I used before. The repository layout is:
repo/
|
|--foo/ (10)
| |
| |-bar1.c (10)
| |-bar2.c (10)
| |-...
- Harry has a working copy of foo on his local disk in directory foo1
- Harry changes bar1.c in directory foo1
- He commits foo1 to foo in the repository -> foo and bar1.c are now in rev. 11
- Sally has a working copy of foo on her local disk in directory foo2
- Sally changes bar2.c in directory foo2
So far so good. But if now Sally commits her changes to foo, subversion doesn't come up with an out-of-date error. Of course, bar2.c is not out of date, but foo2 is and I think that Sally should be notified about the changes in bar1.c.
After Sally has committed her changes, foo is in rev. 12 and neither Harry nor Sally has a working copy that matches the repository.
I wonder if this is intended...
Regards
Christoph
-------- Original Message --------
Subject: Re: no out-of-date error (29-Mrz-2006 18:29)
From: subversion-2006Q1@ryandesign.com
To: subversion@sensor-technik.de
> 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
>
To: subversion-2006Q1@ryandesign.com
Cc: users@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Mar 30 08:43:15 2006