The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
I know the fact of having all the history on any project is far more important than the space it occupies, but let's say I have ended a project, three or four years ago and I simply know the final version is the right one as they have been working in production 24x7 all those years.
And a year or two from now when someone asks "Why does it do X?", having the repo history around to answer the question will be useful. Unless you've done something stupid like putting large binary dependencies in it (I had to deal with one where a genius thought it was the proper place to control the Sql Server installer the app was built with) a code repo should be small compared to the size of modern disks. (In this case I'd suggest making a backup and using GiTs rewrite history feature to preform a stupid binary-ectomy on the repo and leave well enough alone otherwise.)
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
I've seen plenty of funny things in the last Subversion thing I used...
I've programmed machines all my life so usually, the version control is a great help to go back to a previous state if needed, but after the machine has been working for one year at the customer site... then it has no sense keeping all the story...
I've never used it since 1998, anyway, I'm asking it to know if it is possible or not... Let's hope it won't be needed...
GIT is much harder to work with and if somebody - not necessarily yourself - doesn't know how it works, you can lose code. I've experienced that at least twice...
Anything that is unrelated to elephants is irrelephant Anonymous - The problem with quotes on the internet is that you can never tell if they're genuine Winston Churchill, 1944 - I'd just like a chance to prove that money can't make me happy. Me, all the time
I use SourceSafe - because I don't care if nobody else likes it.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 - You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 - When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
if (GIT && SVN) || (SVN && GIT) has redundant boolean redundancies
All humor aside - on a one man team, both Git and SVN will work fine in an offline situation. But with Git, since you have a local repo, you have the opportunity to commit (or branch/merge/whatever) code locally therefore maintaining a local history. With SVN you won't be able to commit (or branch, or merge) anything while offline. So your changes will all get dumped back into the SVN repo in one big pile of committed code (depending on how long you're offline). Of course you can pick through the files and do multiple commits, but what if BUG-2387 and BUG-1209 are both in the same file? In SVN those will appear as one commit if you did them offline. With Git, you can track them as two separate commits.
With Git you can be disconnected, you don't need to pull before you commit, and you get the chance to commit changes locally (eg when disconnected, or for just mucking around) without needing to push your changes to the main repo.
The Pull Request extension is brilliant for those times you want to review changes before integrating them into master.
Even better (and the killer thing for us). If your "main" repo goes down then who cares. Every other copy of your repo has all the history so you just point to another repo as your main (origin).
Git is excellent for those who need to work offline and who realise that things fail.
For Mercurial, better windows GUIs, you won't have changesets disappear (I'm looking at you detached heads) and a whole bunch of other objective and totally sound reasons unrelated to me my intense personal dislike of Git .