So, your FIRST responsibility here is to solve the problem with your process that leads to multiple editors having the file open at once and pare that down to the minimum number of editors you can (hopefully ONE at a time) and then deal with the difficult merge task that's left.
Nifty perforce download code#
Source code is bad enough, but you are dealing with stuff that most revision control systems just store as binary blobs and can usually only tell you that copy x is different than copy y, but not what the changes actually are. Unfortunately, Merging is pretty much *always* guaranteed to be a hard problem, especially when you are merging things that are complex in structure.
If you continue to allow this practice, your issue becomes a question of "how to merge" all this input back into ONE document. You need to think about why the "process" allows multiple people to be editing the same document at the same time. CVS or RCS, or any other "version control system" cannot fix the process problem. If everybody is editing documents all over the place at the same time on shared drives, you simply cannot avoid the *real* problem and that is a process one. The problem you have is a "process" problem. Those where it fails simply put in a technology solution and then wonder why it didn't works they search for the next technology solution.
Nifty perforce download how to#
I've been there and seen it done very poorly and very well the key difference is those who do it well have someone who knows how to make it work, can educate people and convince them why it is important, and actually make it work.
Nifty perforce download download#
After a while they will simply edit the saved copy and, if you're lucky, upload it as a new document.Others will download a document, make edits, save a copy and send it out without ever checking the document back in so no one else can edit it those people will find an older version and simply edit it. Without that, people will download the latest, make edits, save a copy and upload the edited version. Unless you have clear procedures in place detailing how to maintain version control, teach people how to use the software, explain to them why version control is important (and yes that means you, Mr or Ms senior executive who doesn't have time or the need to follow procedures that are in place to prevent the last screwup you caused by ignoring them), and have someone who maintains the document library and keeps it in shape so it actually is easy to use, your solution will fail. The greatest document version control solution will ultimately prove to be useless without considering the human, i.e. And if git ever got decent GUI tools, it would beat its pants off. To reiterate, I like Perforce a lot and found the reward for spending the time to understand its core concepts worthwhile, but its learning curve is steeper than other tools out there. Heck even the built-in MS Office does versioning, but again, that is going to require team training and buy-in.
What they can perhaps nominally hope for is to get everyone to switch to Google Docs which does version control and concurrent editing and merging without you asking. "Hey! I asked Slashdot, and they recommended Perforce (or git or SVN or CVS or VCS or PVCS or whatever!), so just teach that to your colleagues and you're all set!" It's exactly the point that all of these tools are going to require non-trivial training, and do you think this guy is going to be able to tell his wife. As someone who trained people on my team in the video game industry in how to use Perforce who were already familiar with version control concepts, I would reiterate that I don't see any of the above as viable solutions for this bloke.
0 kommentar(er)
