5 ms·

> 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

by mcantor 16y ago

> 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 you commit the binary file and changes to smaller text files in the same changeset? If so, you should be committing them separately. Either you're making small commits to text files that commit almost instantly, or you're making large commits to binary files that you can't "pick out" changes from anyway. Gotta pick one.) > As soon as the commit is published, other people may check it out and try building it... > ... if I can't access the repository server – if it's gone down, or if I'm working remotely – then I can't commit at all. > ... but there are many reports [weasel words] of it being somewhat prone to error. If your mergeinfo property has been corrupted somehow, it might be extremely hard to spot... I see a lot of inconclusive beating around the bush here. The author doesn't want to come out and say that any of these are concrete showstoppers because they are all, at worst, edge cases that experienced svn users mostly know how to deal with anyway. Every VCS has its own bugbears like these, git included. I have been using subversion for years; I do all kinds of insane nonsense with private branches, merging and merge-tracking, large asset commits and all of the things this article uses for its doomsaying. I run into big problems maybe two or three times a year. The writer suggests that git is better. For some reason, even though I have read numerous manuals and guides about git, and have grilled git experts, and have regularly used git myself, and presumably understand how it works, I have to go on a farcical journey into its implementation details every time I do ANYTHING. I always end up in #git, or calling a more git-savvy friend. Everyone inevitably has a different answer that involves a lot of shrugging and "Oh, I guess this actually happened." This was the result even when all I did was follow the instructions at help.github.com/forking, TO THE LETTER. Perhaps I am just a moron, and subversion is just VCS for morons. If so, I am too far gone to realize.

mortice 16y ago
The article and your comment share the same deficiency: they don't deal with concrete problems (or at least when the article does it's about edge cases, as you point out). It's all very well for you to have decided that svn > git for your purposes, and I applaud you for having evaluated the two and chosen one based on relative merits. But in order to extrapolate from that to a general counter-argument to "git is better than subversion," you need to a) provide the details of the problems you had with git and b) explain how they are specimens of a general problem which SVN doesn't have. I don't say this as a git fanboy, just as a techie who hears "I had problems" and instantly wants to hear details so that I can evaluate the argument properly.
kabdib 16y ago
> (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.
- jws 16y ago
  Real world requirements intrude: 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!
- maw 16y ago
  I agree that reproducibility is very important, and it's worth going out of your way get it. 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.
danssig 16y ago
You manage to do all these complex things with SVN and yet you can't manage Git? If this were any other site I would straight up call you out as lying. As it stands I would like to know exactly what it is you're doing that's so hard with Git. 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.
dexen 16y ago
> (...) when all I did was follow the instructions at help.github.com/forking, TO THE LETTER. 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.

by mcantor 16y ago

mortice 16y ago

The article and your comment share the same deficiency: they don't deal with concrete problems (or at least when the article does it's about edge cases, as you point out). It's all very well for you to have decided that svn > git for your purposes, and I applaud you for having evaluated the two and chosen one based on relative merits. But in order to extrapolate from that to a general counter-argument to "git is better than subversion," you need to a) provide the details of the problems you had with git and b) explain how they are specimens of a general problem which SVN doesn't have. I don't say this as a git fanboy, just as a techie who hears "I had problems" and instantly wants to hear details so that I can evaluate the argument properly.

kabdib 16y ago

> (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.

jws 16y ago
Real world requirements intrude: 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!
maw 16y ago
I agree that reproducibility is very important, and it's worth going out of your way get it. 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.

danssig 16y ago

You manage to do all these complex things with SVN and yet you can't manage Git? If this were any other site I would straight up call you out as lying. As it stands I would like to know exactly what it is you're doing that's so hard with Git. 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.

dexen 16y ago

> (...) when all I did was follow the instructions at help.github.com/forking, TO THE LETTER. 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.