On Tue, 26 Jul 2011 15:59:59 +0000, Les Mikesell 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?
...
> 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 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.
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?
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Received on 2011-07-26 23:24:30 CEST