|
<font size="32">WHY2K?</font>
... such stuff as dreams are made on
|
|
|
|
|
<font size="32">!Y?</font>
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
UR2L8!
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
I am NOT too late. It was just a typo. I wanted to write:
WHY3K?
... such stuff as dreams are made on
|
|
|
|
|
Y3K == SEP
SEP / DNA[^]
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Not according to his system clock: he still has 84 years!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Try Y2K38[^] instead.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
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.
At this point I would like to keep only the final version and delete from disk all the previous changes.
Is it possible to make this using SVN or GIT?
I've tried to find it on The Internet without much luck...
|
|
|
|
|
|
It looks exactly what I was looking for OG... Thank you very much!
|
|
|
|
|
You're welcome!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Alternatively, just create a new repository and put the final version in it. Then you can ditch the old repository. (This is probably more effective than cutting off a part of the history).
|
|
|
|
|
That sounds even easier.
Thank you Rage!
|
|
|
|
|
Joan Murt wrote: 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?
--Zachris Topelius
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...
|
|
|
|
|
Which one would you choose and why?
- For a one man team (by now).
- Mainly developing on a laptop.
- Connected to a server only when at home, some of the job is done remotely.
PS: I hope I have not just opened the Pandora's box... I'm a Little out in terms of what is a religious discussion nowadays...
|
|
|
|
|
|
Thank you OG, I'll read that article and see...
|
|
|
|
|
|
I use subversion.
Not the Apache product; just subversion.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
SVN - any day!
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
|
|
|
|
|
I went of SourceSafe when it totally corrupted our repository.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
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.
|
|
|
|
|
Excellent reply, very good points for the situation described. Have an upvote.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|