On 7/26/11 4:23 PM, Andreas Krey wrote:
>
>>> Because the commit came from my WC. My WC was up to date before the
>>> commit, and the only things that change have been in my WC already,
>>> so there is no possible way my WC can not be up to date. Except that it
>>> 'forgets' to update the WC revision info, and requires a separate update
>>> for that.
>>
>> It doesn't 'forget', it knows that doing it right would, in the general
>> case, involve changing files in your working copy that you might not
>> want to have changed.
>
> In what case? When svn lets me commit at all, it is when the WC is
> up to date; that is, there is nothing that needs to be merged into
> my WC. What files could need to be modified, under the assumption
> that the WC wasn't mixed-revision to begin with?
In the typical case of concurrent work, someone else will have committed a
different set of files before you. Your commit only pushes your changed files.
Now your workspace and the repo head are very different.
>> While in this case you may 'know' that no one else has made any changes
>> in the repository, but it is probably a bad idea to get into habits that
>> won't work when you are part of a team.
>
> I seriously don't know what you mean here. If an 'svn up' wouldn't change
> anything in my WC before I do a commit, an 'svn up' immediately after
> my commit (to the revision I committed) wouldn't do either, and there
> is no reason why that shouldn't be reflected in the WC by the commit
> instead requiring me to do a separate update.
In the general case, you don't know that. Any number of other things may have
happened in the repo before or after your commit. It is sort-of a special case
when there have been no other changes and I suppose it wouldn't hurt anything in
that case if subversion marked your WC as updated to the next rev, but then it
would be very confusing when there were changes and it didn't.
> In any case, there is always the chance of someone beating me to the
> commit, so I need to update beforehand. But that can happen before the
> first commit just as well. And for most cases two consecutive commits
> just work; I did need some time to come up with the scenario.
Consider changes to different files than the set you commit. Your commit won't
have conflicts but you won't have (and may not want) the other changes yet.
> Btw, is there a way to undo an update that lead to merges with my changes
> (or even conflicts), and get back my original modified sandbox?
If you accepted their changes in a conflict, probably not. But if you can
figure out the revisions before/after the changes you want to back out you
should be able to reverse-merge that change.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2011-07-27 01:54:20 CEST