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
