Ben Collins-Sussman wrote:
> Bob Proulx wrote:
> > At the time of
> >the commit your working copy must be up to date with the repository
>
> Incorrect.
>
> Suppose the repository is at r10.
>
> Suppose you have a working copy with two sibling files, 'foo' and 'bar'.
>
> Now you commit you change to 'foo', and the commit succeeds,
> informing you that you've just created r20.
>
> r20? How is that? Well, apparently other people have been making
> changes too.
I have always been working with updated working copies and I always
commit from a freshly updated working copy. Therefore I have missed
seeing this behavior. Additionally I somehow got the idea that if my
working copy was out of date at the time of commit that the commit
would have been pushed back to me. This is why I had assumed that at
the time of commit that my working copy would generally be up to date.
But now I guess I am to understand that only the file I am committing
changes to needs to be the same as the HEAD version? (I know I should
try some test cases but time is passing.)
> If, immediately after the commit, the svn client were to simply mark
> your entire working copy as being at r20, it would be a complete
> lie.
I was not saying that it should simply *mark* them up to date. I was
saying that a commit should explicitly be followed by an update. I
was saying (erroneously) that the update operation should be fast at
that time because there would be no changes between the WC and the
repository at that time. I understand that you are correcting this
and saying there may be large changes and therefore it follows that it
might be a slow operation instead.
I need to try some test cases. Because now I fear from what I have
just learned that I may think I am making a perfectly consistent
change against my BASE version and wanting to commit it. But there is
a time when someone else is thinking the same thing and making a
related change but perhaps in a different file. And even if I update
immediately before my commit this other person may beat me into the
repository.
If we make those changes in non-conflicting (from a version control
point of view) ways both succeed even if they are incompatible
changes. Therefore after a commit it is now doubly important that I
update and test again to make sure that this has not happened or it
may be my change, which by happenstance occurred second, to be the
breaking change. And the same in reverse for the other committee.
True?
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 19 08:10:07 2005