3 messages in com.perforce.perforce-user[p4] Re: perforce-user digest, Vol 1 ...| From | Sent On | Attachments |
|---|---|---|
| Larry Blair | 02 Jun 2000 13:57 | |
| Gregg G. Wonderly | 02 Jun 2000 14:43 | |
| Ken Rice | 02 Jun 2000 14:45 |
| Subject: | [p4] Re: perforce-user digest, Vol 1 #243 - 11 msgs |
|---|---|
| From: | Gregg G. Wonderly (gre...@skymaster.c2-tech.com) |
| Date: | 06/02/2000 02:43:50 PM |
| List: | com.perforce.perforce-user |
You are thinking about source files. Binary files are not mergable. Simultaneous changes cannot be resolved.
No, all file types demand conflict resolution. When I say merge I mean do whatever it takes to make sure that all changes end up in the final version. If it's an image, I'd load it up, look at the differences and either make the final image contain everything, or go talk to the person making the last change to find out what I needed to include in the version I submitted. If people are working together and responsibilities are not divided in someway where file ownership can be used as part of the change approval or change execution process, you will never find that SCM or anything else makes it possible for your system to be consistant!
At some point, file locking is gonna kill progress. At AT&T/Lucent, I used an SCCS based system called ECMS that used file locking, which all engineers thought was the worst feature of the system (4000 engineers that is). People would leave for vacation, or early weekends and leave files checked out. A hot problem would come up and we'd have to build private fixes with private files because we could not create and submit an official change.
Locking files sounds like an easy solution, but I would suggest that a little more structure and some primary file ownership would direct changes to occur by one person on most files most of the time and very rarely will you need to do a "merge" on a binary file that requires massive effort.
The problem is that everyone who needs to change one of these files must be aware that they need to lock the file. It is _never_ ok to modify the file without locking, so Perforce should provide a mechanism that will mark specific files so that they are automatically locked on checkout.
Well, I think is already been said that when the file is checked out, perforce does tell you that the file is already checked out, or locked. If they can see the locked message, then surely they can see the already checked out message.
How can you keep working? Any changes you make are unmergable and will be lost (unless you write over someone else's changes and their's are lost).
Perforce demands conflict resolution at submit time. If the user choosed to just say "take mine", then yes, changes get lost. People have to learn that somethings take time to execute. If file locking happened automatically, then the time that you are currently spending on resolving missing changes or that users would spend on useful merges would be taken up by phone calls and pleading and negociations to let the person needed to make the 2nd or later of a set of conflicting changes.
So, time will not be saved by providing automated locking. Instead, time can be saved by not locking the file so that only the slowest to make changes are burdened with the task of merging their changes with someone elses.
----- gregg at c2-tech.com (C2 Technologies Inc)