On 04/03/11 00:55, Bill Brutzman wrote: > It is not clear to me how SubVersion and GIT developers refer to the latest > rev of their subs. Also the reverse...what programs use the subs. This is > where OSGI fits in. I have heard rumblings that people are working on an > Eclipse-compatible OSGI SCM thing. OSGI is worth learning about. OSGI is a > configuration tool that grew up out of the cell phone industry to handle > config control on say, a Nokia family of products.
Git, certainly, you have two techniques. The commit ID for any given file(s), and the tag or branch for any given "application". Application in quotes because it can refer to as much or as little of your system as you want. I'm currently playing with / learning git. The whole point of a DVCS is that there is NO master copy, other than by convention. So each developer is likely to have their own development account, and then there's the central development account. Where git really scores (dunno about other systems) is the ability to switch between different problems very quickly and easily. You could have a long-term project you're working on, and a medium term development job. It's dead easy to switch between the two - "commit a; checkout b" and you've just changed from one to t'other. Then someone might come to you with "drop everything - we've got a problem on live" so "stash; checkout new branch from live" and you're running on a copy of live, in a new branch, where you can modify and test things. Once it's all working, "commit; push to live system" (or "pull from live system") and the fix has gone live. "drop copy of live; checkout development"; and you're back where you started. And the nice thing is, every time you change branch, or every morning or whatever, you can do a "pull; merge" and you're development copy keeps in sync with all the changes every one else is making. And these commands probably take longer to type than to run :-) But I would say, even if no-one else in your organisation is using it, it's a damn good tool for you to use for your own work. If you've got several people working on a centralised VCS, I've had enough pain where we've been tripping over each other trying to update the same file. You can have a master branch tracking the central system, then do your own development in your own branches. When you need to commit, sync your master with central, check out central, merge your changes into your master, then commit back to central. That way, you're not held up because you can't check out a file, and you're not swearing when you're half way through make a LOT of not-so-important changes, and someone comes along saying "you need to check that back in, I've got an emergency to fix!". I'd say play with git! It's a nice system, and there's absolutely no need whatsoever for it to impact on anybody else around you, unless you want it to. And other people will probably start using it too, once you realise how nice and powerful it is. Cheers, Wol _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
