On 5/19/05, Bob Proulx <bob@proulx.com> wrote:
> 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?
>
Something you can setup, and our team appreciates, is a post-commit
hook script to send an email after a commit detailing the changed
files and the log message. Very nice for knowing when changes have
occured.
We use the Perl module SVN::Notify
(http://search.cpan.org/dist/SVN-Notify/) to simplify this. It works
really well.
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 19 13:59:31 2005