71–80 of 112 posts
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.
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.
I fail to see your point. Every copy of a git repo is a full copy [1] - unlike a svn checkout. If you follow a centralized server model with git you have a copy on the server and every workstation it is checked out on. With svn, the full repo only exists on the server. Why couldn't you have a redundant, backed up central git server? [1] Not a substitute for real backups of your repo!
Admittedly, this is a bigger problem in svn if you aren't using branches for work-in-progress.
> 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.
On the other hand, it's not entirely clear that you should include all that stuff inside a source control repository. This is something I've grappled with myself, in a number of contexts, and I don't have any great answers. In fact, I've usually just done what you do.
Still, given the time and incentives to really do it right, I think a better solution would involve keeping metadata versioned, and storing large binary files extra-repo. Within your repo, you'd have a file or a set of files that indicate that the tools you're using to build/test/deploy/etc are all contained within one or more uniquely identifiable tarballs. Your build process would have a way to extract the contents of those tarballs, if necessary.
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…
> We sometimes even actively try to deny others the very powers we refused to take.
Huh? Who was that directed at?
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?
You are absolutely right about the way to propagate changes in ideas, prerequisites, protocols etc. etc.. Actually, I'm a frequent whiteboard user myself.
I should've made myself clear I was meaning the physical changes to the implementation files; in any case, something that is byproduct of information shared verbally.
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.
This and more of the same. One loony (who I now thankfully don't have to put up with any more) was always making changes without merging them back into source control, meaning things were marked as addressed in issues logs but there was no corresponding update in the source tree. Lucky we were using a checkout-and-lock model at the time (small team, with each of us generally working on distcint areas, so this didn't…
> 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…
Well there's your problem, to quote certain TV personality.
Git supports several different workflows. Each one is valid. Some of them are incompatible with one another in some cases. Now everybody gives you instructions that make sense in his workflow. The instructions are correct, you apply them correctly and get a correct result.
Only that the result does not make sense in the (different, but valid as well) workflow that you use daily. That will happen sometimes if you don't make upfront a plan of what comes, or derives, from what, if you don't visualize what line of development merges into, or rebases onto, which.
But hey, presto! You can always git-reset your branch (read man first!, that's powertool and must be applied with care), or git-cherry-pick (fun and easy) some changesets and you are back on track.
Best thing is, if you somehow get into a tight corner, you can just remove this branch or repo and start afresh, if you haven't pushed to the server yet.
Push decoupled from commit is your ultimate parachute -- and comes with a backup parachute of local branching.
tl;dr: don't follow $RANDOM_INSTRUCTIONS; make a plan upfront and you'll know where you are at every step. And should that fail, deploy either parachute.
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.
Nothing worked anymore and the IDE managed only to spew out a dialog error saying `Nieprawid.'.
In git, cleaning the server up took just some command typing on developer machine. Could have been done from TortoiseGit, if they wanted to. The best thing is, the clean-up was `perfect' in that it left no traces of the fubar whatsoever. No faux merge left to trip up future merges by mis-placing the base version. Yay <3
Do not confuse elitism with minimalism. Git is simply easier to use, and harder to shoot yourself in the foot with - at least when it comes to the basic flows. (Granted, you can blow your face off with git if you really try hard). When branching in git is a simple git checkout -b newbranch away as opposed to svn copy http://repo.com/some/path/to/trunk http://repo.com/some/path/to/branches/somenewbranch - then what el…
> Git is simply easier to use, and harder to shoot yourself in the foot with - at least when it comes to the basic flows. (Granted, you can blow your face off with git if you really try hard). I don't know. I've trained a lot of developers with Subverison, Git, and Mercurial. Subversion is the one that I've honestly had the least trouble with, and Git the most. Heck, early on with git I had instances where the repo w…
In git, you can just push a clean branch on the server, if you take some caution. No elevated privileges needed. Actually, most of the time it won't be necessary, because the user will simply not push a wrong merge to the server. No need to clean up.
Actually once in a while I do torch whole repo (both .git and checked out files), but that's only when I was experimenting with something and didn't like the result. Cheap local cloning of Git repos makes that experimentation fast, easy & safe.
On the other hand, if I ever have to really, positively clean the repo to a known state, `git co -f $SOME_BRANCH' or `git co -f HEAD'; end of the story. Perhaps also remove the leftover untracked files, if I was cleaning merge abandoned in progress.
--
[1] as I described here: http://news.ycombinator.com/item?id=2310065
Earlier quoted context omitted.
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…
Well, in my case it's not a submarine, but a train. And yes, it is great advantage that I can freely make a branch with the new feature that I just started working on, without having to summon a meeting to let everyone know that a new branch will be created, which is not intended to be used by anyone else even if it's visible to everyone.
As for working offline, my choice of the submarine example was intentional. 10 years ago I used cvsup (and later, svk) to work on the train and plane while using cvs and svn. That mode of working predates git quite a bit, but it's also much less useful nowadays -- Now I just use phone tethering and inflight wifi. I'd be working less efficiently without Internet resources at hand, so now that wireless technology has caught up, I don't have to.