On 15/11/11 20:47, Barber, Bonnie wrote:
I will be glad to, if I ever get it figured out.  I am still confused by all 
the new verbiage that goes with it, for instance the statement in the reply 
from WOL Lists:
Except that - iirc (I use git) - mercurial is a DVCS, so the concept of check-in/out 
no longer exists ...<<

I am just an old PICK person; this is all new stuff to me, LOL!!

DVCS - Distributed Version Control System.

The whole point of which is that there is no central master. In practice there is, but the software doesn't assume it (and in git's case at the software level actively blocks it).

Take LibreOffice for example. There is a central repository that the developers recognise as the "master copy", and all official releases are made from that copy, but as far as the software is concerned there is nothing special about it.

The copy on my hard disk is identical to the master copy. It's just that the typical guy can only copy *from* the master. I happen to have a key that lets me push *to* the master.

But if I want to push my changes, I first sync my master copy with the central copy. Then I sync my development copy with my new master copy. Then, because I can, I push my changes from my master to the central copy. Somebody without the key would have to publish those changes and wait for somebody like me to add them to my system, approve them, and push them.

Contrast this with my experience of Visual Source Safe, where I would be working on a module when somebody else needed to do an urgent bug fix. They couldn't bug-fix because I had the module checked out, so I had to abandon my changes and release it to them, wait for them to bugfix, then reclaim it and redo my changes. A right pain in the proverbial...

Git gets round this by letting me develop in isolation, then helps me sync my work with all the changes that others have made, before pushing my changes into the master copy.

It's even better than that, because if you're a lone developer it allows you to develop multiple paths in isolation from each other, and only merge each change into the master copy when you've tested it and are happy with it. So if you suddenly discover a nasty bug in the module you're doing new development on, you can stash your development away and revert to the live version, fix the bug, revert back to the development version, and roll the bugfix forward into the development version.

If you've got no version control system, even if you're a developer in a decent-sized shop, try installing git and playing with it for your own work. Even in that Visual Source Safe hell I described, it's great. You can develop without needing to check out from the centre. And when you're happy with your code, you sync your master branch with the centre, checkout the code from the centre, merge your changes into the master, check it again in case somebody else's changes break your changes, then commit your changes and free the centre. That way you could have been developing for weeks, *without* interfering with other developers in the process - you only need access to the checked-out copy for as long as it takes you to check and QA your changes.

U2-Users mailing list

Reply via email to