Re: Weird need for "svn update"

Tyler Roscoe wrote:
> On Wed, Jun 10, 2009 at 03:27:54PM +0200, Neels Janosch Hofmeyr wrote:
>> mkdir dir
>> echo fool > dir/foo
>> svn add dir
>> svn ci -m log1
>
> As soon as you commit here, you have changed the repository:
> revisionNumber++.
>
>> ## The problem disappears when removing this edit:
>> echo once > dir/foo
>> svn ci -m log2
>
> So when you go to commit here, you're using a working copy that doesn't
> have the "latest" from the repo, hence the error. Yes, that change came
> from this very working copy, but I'm guessing there are weird corner
> cases you can get into if your working copy doesn't force you to update
> here before committing something else.

I added `svn info' calls and I see that my working copy root stays at rev 0,
and dir stays at rev 1.

But thinking about it, I don't see why Subversion needs to do that.
If I commit dir/ recursively, the next revision of dir/ will be exactly what
is in my working copy right now (generally), right?

Why doesn't subversion recognise "Ok, this new HEAD revision is created by
me, and this unchanged directory is one of my targets. So I know that this
directory is unchanged in the new HEAD. Thus, the dir must now be at HEAD."

This assumption in fact only works when said dir is up-to-date. But in my
example, it initially is up-to-date, until a commit fails to tag along the
up-to-dateness. At least when a target dir is up-to-date, surely a commit
could drag along that dir's rev to HEAD?

What am I not getting?
That this is a missing feature? ;)

Thanks,
~Neels

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2361070

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].