61–70 of 112 posts
Earlier quoted context omitted.
"someone always has it worse." Unfortunatelly, not in your case. ;)
What was the name of that version control tool before CVS, RVCS? Back in 2007 I had heard one very big name hardware company using that for version control and planning to move to CVS as they thought the former was beginning to show its age.
Earlier quoted context omitted.
> Can you do the same, if not better, job with alternate, less efficient tools? The question is: Is a tool just 10% more efficient or does it introduce a whole new quality of working with it? What do you do when your already delivered software has a bug that needs to be fixed urgently, but you already started to add new features that are not ready yet? Using branches with svn is a thing just everyone is scared of (an…
I don't understand the branching mantra that I hear from git proponents. Subversion has had merge tracking since 1.5, and with it, branching and method is as painless as it can reasonably be. Unless you want to work on a submarine, or have an organizational need for people to maintain private unpublished branches (eg, open source), I don't really see what advantages git has to offer over subversion in organizational…
> If I'm committing some large assets... (Isn't version control mostly for text files?) > If, while the upload's been happening, I've made more changes to my working copy... (So you're uploading a large--presumably binary--file, and you're continuing to work on it while it's committing...) > I have to carefully pick out my new changes and keep them separate from my old changes. (Wait, what? In a binary file? Or did y…
Personally I hate command line interfaces and try to do everything I can in the windows Git GUI. I have to fall back on the command line a lot for cherry picking (when the GUI wont do it for some reason), stashing, rebasing (including various kinds of history rewrites), complex merging, conflict resolution, etc. and I find this easy to do with very little training (mainly just the Git pro online book). I would never even attempt the things you do with SVN because it would just be way too complex.
Earlier quoted context omitted.
Exactly! I have 15 GB of svn repositories. I don't plan to migrate them. I use mercurial for new projects and I'm fine with old stuff to live in svn. Just like I use more than one programming language, I use more than one OS, I use more than one database backend...
Whenever I'm touching one of my old projects (some even in CVS), I'm migrating them to the system I'm using at the time. Currently that's git. So now I'm looking back on 52 repositories. 16 in CVS, 14 in subversion and 22 in git (all of them counted only once) created over the last 10 years.
Earlier quoted context omitted.
Perhaps you want to re-read on git-reset. You can always rewind history to some arbitrary point and re-stack operations, both en-mass and step by step You can re-write branches locally and even on the server. It's to be used very rarely & carefully, but it has gotten the other team at my workplace out of a tight spot just two days ago.
Whereas with a simpler tool like subversion, there will be no tight spots.
The big risk I always see with git is that you start storing more and more work locally. This exposes you to the chance of hardware failure on a desktop pc. With svn, it would be easier for the hardware to be redundant and backed-up.
Then again I usually felt safer if his work wasn't in source control anyway. I often thought it might be quicker to stay late and do the work myself from the start instead of staying late fixing his work as often as I needed to...
> If I'm committing some large assets... (Isn't version control mostly for text files?) > If, while the upload's been happening, I've made more changes to my working copy... (So you're uploading a large--presumably binary--file, and you're continuing to work on it while it's committing...) > I have to carefully pick out my new changes and keep them separate from my old changes. (Wait, what? In a binary file? Or did y…
> (Isn't version control mostly for text files?) No. For long-life projects I snapshot entire build systems (toolsets, documentation, you name it) so that a precise image can be re-created later.
Years ago, in our 100+ coder company I kept finding copies of Microsoft's Developer CDs in CVS. Everything to set up a build machine was in there.
Furthermore, because developers sometimes didn't all have the same build environments, all of the intermediate builds were also checked in since you couldn't assume your machine would build exactly the same executable code as anyone else's machine.
CVS was definitely not built for this, but it worked. And if it works, and a programmer thinks it solves his problem, it will be used.
I discovered this because we kept getting problems with orphaned CVS locks, and people complaining of the slow checkins (CVS did the diff on the server, so upload the slow way over your ADSL line all those giant files that didn't change.) Which led to the day I typo'd a lock removal command and deleted all files with "rfl" in their name. Not a common sequence, unless your software deals with "overfly"s. Hurray for backups!
Earlier quoted context omitted.
You are mistaking the tools you use for the tools that a team can use. That's Git: it lets teammates communicate changes in a straightforward, consistent manner, with little overhead. With a tool suite to review, pull en mass or cherry-pick the changes at will; with the defaults being the most practical choices most of the time. If you want your team to be more than a sum of the members (as opposed to stepping on eac…
Just to play devil's advocate here, and definitely not disagreeing with you, but... Do you know how we communicated changes before git and other team tools? With our voices, markers, and boards. If your team steps on each other's toes, might that not be a problem with the team dynamics and not necessarily the tools themselves?
Earlier quoted context omitted.
And yet some of us are stuck using CVS.
Some of us are stuck using Clear Case or Visual Source Safe. Whatever source control you're using, someone always has it worse.
I'm kinda annoyed that every once in a while, somebody has to come along dissing svn, prophesying its inevitable demise and glorifying git. Yes, git is "better" than svn, I agree. I like the message in general, but I don't like the tone of it. I still use svn. For personal project, I have moved to hg. I use git occasionally. They all have its merits, and svn certainly didn't deserve "you should probably stop using it…
> They all have [their] merits That is a poisonous meme which should be fought tooth and nail. It basically follows the structure of the fallacy of grey¹: "every tool has qualities, therefore they're all fine". It doesn't account for the fact that some tools dominate others. Meaning, they are demonstrably better in every way for every foreseeable usage. But we tend to cling to our old ways, instead of just saying "oo…
I said in my comment I agree with the post in that git is "better" than svn. But svn is not that bad that it deserves a jihad of git users that can not stand not having world domination of their fav tool. That is ridiculous.