Weird need for "svn update"

[Neels Janosch Hofmeyr <ne...@elego.de>]

Hi all,

I've got this script attached which doesn't run smoothly when a specific
update is missing (see comment in the script).

This is the same for 1.5.6, 1.6.2 and trunk.

Can anyone explain to me *why* that update in there is necessary?

Thanks,
~Neels

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

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

Re: Weird need for "svn update"

[Neels Janosch Hofmeyr <ne...@elego.de>]

Regarding this, stsp pointed out to me:

http://subversion.tigris.org/faq.html#hidden-log

and it's probably done like that for performance reasons.
I'm done wondering. It stays like this. ;)

Thanks for your patience,
~Neels

Neels Janosch Hofmeyr wrote:
> 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@subversion.tigris.org].

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

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

Re: Weird need for "svn update"

[Neels Janosch Hofmeyr <ne...@elego.de>]

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@subversion.tigris.org].

Re: Weird need for "svn update"

[Tyler Roscoe <ty...@cryptio.net>]

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.

hth,
tyler