Thanks Felix, that makes sense.
From: Felix Gilcher [mailto:email@example.com]
Sent: Thursday, March 16, 2006 10:19 AM
To: Jiri Culik
Subject: AW: RE: Directory Modification Feature or a Bug?
Jiri Culik <mailto:firstname.lastname@example.org> schrieb am Donnerstag, 16. März 2006
> Thanks for the reply.
> Well I searched through the information that you suggested,
> but I still
> don't see an answer.
> Also saying the automatic update after commit of a modified directory
> (only the directory without recursion) is a Bad Thing does not make
> much sense.
> If it is a Bad Thing, than why would I be able to do it
> manually, and in
> fact be required to do it manually in order to get my simple example
> to work?
the simplest example that comes to my mind:
1 user a checks out directory d.
2 user a adds a file to directory d
4 user b deletes file x in the directory d and changes some files in
directory e that used to depend on file x (--> this is a change to the
5 user b commits his changes
6 user a commits his add
If the directory is updated after user a commits, he would have to deal with
the changes that he recieves but never asked for (the delete of file x).
Especially, since this is a partial update only, he might run into build
problems, as he still has the old version of directory e with the files that
depend on file x. So now, he has to update his whole WC to get a working
version, which might incorporate even more changes that he doesn't want to
cope with at that moment.
And all of this just because he did some minor commit? This is why
"autoupdates after commits" are regarded 'A bad thing (tm)' and I prefer it
the way it's right now.
Allowing this behaviour to be turned off with a switch would not help, as
user a would need to check the log before committing, otherwise he'd have no
clue that he might recieve changes. And even with checking the log, he might
not be shure as there is a short window between him checking and him
committing in which someone else might commit.
So the default behaviour would have to be 'autoupdates off' and a flag to
turn it on. There's no need for that however, as you can easily write a two
lines script that does exactly that - commit and update the current
> All I am saying is that the commit command should do the
> update after the
> commit, and if there are exceptional circumstances when you
> would not want
> it, perhaps that could be disabled using a switch.
> Maybe an example of why this is a Bad Thing to do it
> automatically, but not
> a Bad Thing when doing it manually would be good.
The primary reason is: I want to update when I'm ready to deal with any
conflicts arising from my own actions.
Head of IT Development
Exozet Berlin GmbH
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Mar 16 22:02:05 2006