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
lesmikes...@gmail.com
