Jiri Culik <mailto:email@example.com> schrieb am Donnerstag, 16. März 2006 15:53:
> 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 directory)
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 directory.
> 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: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Mar 16 16:22:50 2006