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.
Cheers,
Wol
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
