svn info bug?

[kb...@gte.net]

I made a change to some files and I noticed the "info" data didn't seem to be 
changing.  So I tried again.  First I did a "svn up" and then an "info" showed 
me the correct data (I am on rev #4 going to #5).  I changed some files, then:

[178 ~ /home/kevin/stepr/wc] svn info
Path:
Url: file:///home/svn/stepr
Revision: 4
Node Kind: directory
Schedule: normal
Last Changed Author: kevin
Last Changed Rev: 4
Last Changed Date: 2002-11-06 22:10:16 -0600 (Wed, 06 Nov 2002)

[179 ~ /home/kevin/stepr/wc] svn status
M      Step.pm
M      Step0.pm
A      volume.cd
[180 ~ /home/kevin/stepr/wc] svn commit -m "fixed bug that ignored duplicate 
section names"           <
Sending        Step.pm
Sending        Step0.pm
Adding         volume.cd
Transmitting file data ...
Committed revision 5.
[181 ~ /home/kevin/stepr/wc] svn info
Path:
Url: file:///home/svn/stepr
Revision: 4
Node Kind: directory
Schedule: normal
Last Changed Author: kevin
Last Changed Rev: 4
Last Changed Date: 2002-11-06 22:10:16 -0600 (Wed, 06 Nov 2002)

# bad, we should show rev 5!

[182 ~ /home/kevin/stepr/wc] svn up
At revision 5.
[183 ~ /home/kevin/stepr/wc] svn info
Path:
Url: file:///home/svn/stepr
Revision: 5
Node Kind: directory
Schedule: normal
Last Changed Author: kevin
Last Changed Rev: 5
Last Changed Date: 2002-11-06 23:46:14 -0600 (Wed, 06 Nov 2002)

Now we're good only after the "up".  Is this a real problem or do I 
misunderstand the process somewhere?  I thought that as long as I was the only 
developer with only 1 working dir, I'd never really have to do an "update"; 
true or false?  If false, why?  (if this is in the handbook, I didn't see it, 
and I did look)

Thanks,
Kevin


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

Re: svn info bug?

[Ben Collins-Sussman <su...@collab.net>]

Ben Collins-Sussman <su...@collab.net> writes:

> If your working copy is all at revision 4, and you commit one file
> which creates revision 5, then that file is now at revision 5.  That's
> it.  Your working copy is never changed unless you explicitly fold new
> changes into it by running 'svn up'.

Hmmm... let me clarify what I'm guessing might be the confusion here.

Say your working copy is all at revision 4, and you commit one file
which creates revision 10.  (Other people have been committing.)  So
now what should your working copy do?  Obviously, your copy of the
freshly committed file comes from revision 10.  But what about the
rest of your working copy?

It would actually be *wrong* to claim your working copy is at revision
10 overall.  What if somebody added or deleted something somewhere in
revisions 5 thru 9?  There's simply no way to know without asking the
server to update your working directory to rev 10.  And as I said
earlier, we don't want commits to automatically cause updates.  

Thus after every commit, you end up with a mixed-revision working
copy.  Not a big deal really.  Many people do that on purpose: they
want to lock a directory or file at a certain revision, or mix and
match different pieces of a tree by using 'svn up -r' or 'svn switch'.



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

Re: svn info bug?

[Ben Collins-Sussman <su...@collab.net>]

kbrannen@gte.net writes:

> Now we're good only after the "up".  Is this a real problem or do I
> misunderstand the process somewhere?  I thought that as long as I was
> the only developer with only 1 working dir, I'd never really have to
> do an "update"; true or false?  If false, why?

You need to read chapter 2 of the book, particularly the last section.
In particular, this is a matter of understanding how mixed working
copies work.  (Mixed-revision working copies, by the way, is nothing
new.  It's a concept from CVS that we like very much.)

If your working copy is all at revision 4, and you commit one file
which creates revision 5, then that file is now at revision 5.  That's
it.  Your working copy is never changed unless you explicitly fold new
changes into it by running 'svn up'.

(The only alternative to this behavior is for every commit to *cause*
an immediate update of your whole working copy.  And that mixes two
concepts that we don't want to mix: changes should only be submitted
when you run commit, and changes should be received only when you run
update.)

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