Quote:Original post by Zahlman
OK, I'll bite. What does git do that I didn't previously realize I need a version control system to do? Because SVN already does everything I can imagine a version control system doing for me, and more. Well, except binary diffs.

I can take a stab at this question..

* Control over your merges. With Subversion, whenever you do "svn up", it will automatically merge your local changes against the new head, and you have no ability to undo this merge. With Git, you can fetch the upstream and look at it without merging anything, and you can also undo a merge and go back to the exact copy of your files before a merge.

* Cleaning up history. When I work, I like to make lots and lots of "checkpoint" commits, as a form of long-term undo. But when I share my work, I don't want other people to see all those little commits, so I use 'git rebase' to squish them all into one logical commit. Or the opposite, if I end up needing to do lots of changes at once, I can split up one big "Fix a lot of stuff" commit into smaller atomic commits.

* Trivially easy branching. You can branch in SVN but people don't do it as often, because it's not as easy.

* There's a 'clean' command. SVN needs this command so badly.

* And then there are little things about SVN that annoy me: having to use "svn add", "svn rm", or "svn mv" instead of just adding/removing/renaming the files whenever you want, having to avoid all those damn .svn folders, or no easy way to ignore a filename pattern across the whole project.

Quote:Original post by pinacolada
* Trivially easy branching. You can branch in SVN but people don't do it as often, because it's not as easy.

That's not true. SVN branching is trivial, and lots of people do it often. The problem SVN has is with merging, which has been alleviated somewhat in the 1.5 release with the addition of merge tracking. For instance, I once had a repository that included "orphaned" items (exported from SourceSafe and then imported in SVN) that I wanted to marge into an existing branch. Because of the manner in which SVN performs (performed?) merges, orphaned items caused a huge amount of trouble because it could not locate their root nodes.

SVN has tremendous weaknesses in repository management/administration. svnadmin is a cute tool, but for real work you have to get into svndumpfilter or even manually editing dump files (which are huge).

Quote:* There's a 'clean' command. SVN needs this command so badly.

svn cleanup

Quote:* And then there are little things about SVN that annoy me: having to use "svn add", "svn rm", or "svn mv" instead of just adding/removing/renaming the files whenever you want, having to avoid all those damn .svn folders, or no easy way to ignore a filename pattern across the whole project.

svn propset svn:ignore ... and the global-ignores section of the SVN configuration file.

Quote:Original post by Oluseyi

Quote:* There's a 'clean' command. SVN needs this command so badly.

svn cleanup

That doesn't seem to do the same thing. 'git clean' has two forms, one is that it deletes all the untracked files or directories in a certain path. For example, you could use it to delete those extra files that get spit out whenever there's a conflict (in SVN they are the .rXXX and .mine files). What is a good way in SVN to delete all those? And there are other ways that SVN leaves extra crap around. Let's say I 'svn merge' something, and that adds a bunch of files/directories. Then I change my mind and I 'svn revert' everything. Now I still have all of the directories that were added in the merge but not present in my original checkout. How do I get rid of those?

The other form of 'git clean' is where it deletes untracked stuff, including ignored files. This usually deletes all of your build artifacts, and it's a nice way to get a set of files which is guaranteed to be the same as a clean checkout.

Quote:
svn propset svn:ignore ... and the global-ignores section of the SVN configuration file.

"propset svn:ignore" needs to be set on every single directory. That's annoying. "global-ignores" is too global and it needs to be re-specified for every client machine.

If I'm running a big Python project, then I want a *project-specific* way to say "Ignore .pyc files across this entire project". I don't want to do "propset" for every directory and I don't want to have to tell everyone, "by the way you should update your global-ignores so that you don't see .pyc files".

SVN is nice (coupled with TortoiseSVN, as mentioned), and there is a ton of free, easy hosting. Unfuddle.com, Freepository.com, etc.

BTW, I like Unfuddle personally. You get some primitive project management and good web access.

Quote:Original post by Sneftel

Quote:Original post by Zahlman
OK, I'll bite. What does git do that I didn't previously realize I need a version control system to do? Because SVN already does everything I can imagine a version control system doing for me, and more. Well, except binary diffs.

Was reading this the other day, might be worth a look. I have very little personal experience with Git, but I have plenty of experience with SVN and Perforce, and the author's contention that source code control should mean never having to hear "you should have..." resonates with me.

See, my process for dealing with the "tangled working copy problem" looks like:

1) Duplicate the tangled file.
2) Use the diff tool to revert the parts I don't want to commit.
3) Commit.
4) Rename (file system operation, not SVN operation) the duplicate to overwrite the just committed file, producing the new working copy.

Which is really the same thing as the process described with git, except that I have to (gasp) do the actual backup and restoration. In exchange for that, I get to use a GUI for diffing. I have no idea why this simple process hasn't occurred to the author, either.

Quote:Original post by pinacolada
For example, you could use it to delete those extra files that get spit out whenever there's a conflict (in SVN they are the .rXXX and .mine files). What is a good way in SVN to delete all those?

Um... resolve the conflict. They should disappear automatically. I've never had them fail to do so.

Quote:"propset svn:ignore" needs to be set on every single directory. That's annoying. "global-ignores" is too global and it needs to be re-specified for every client machine.

Agreed, SVN 'propset' has issues. At my last job, I wrote a script to walk the directory tree and reapply the changes. It would also mark things for deletion if they had been added and would be ignored with the new changes, and let a human pull the trigger.

Quote:* Cleaning up history. When I work, I like to make lots and lots of "checkpoint" commits, as a form of long-term undo. But when I share my work, I don't want other people to see all those little commits, so I use 'git rebase' to squish them all into one logical commit.

I just don't comment the little ones.

(EDIT: The 'git commit --amend' mentioned in the blog article does seem like something I'd get a lot of mileage out of. :) )

Quote:Or the opposite, if I end up needing to do lots of changes at once, I can split up one big "Fix a lot of stuff" commit into smaller atomic commits.

I can't imagine a way that could be made easy.

Quote:And then there are little things about SVN that annoy me: having to use "svn add", "svn rm", or "svn mv" instead of just adding/removing/renaming the files whenever you want

In exchange for that, you get to keep unversioned files without expending any effort to keep them unversioned. (The ignore list isn't really necessary, unless you have people on the team who mindlessly check 'select all'.)

Quote:Original post by Bregma
Atomic commits. 'nuff said there.

As noted, SVN has them.

Quote:Always available (you can commit any time, even working on your laptop at the lake or at the airport while your flight is delayed). The more often you commit, the less you have to recover.

I'm not aware of a sense in which my SVN repository is not "always available" in which a repository possibly could be. Especially not for single-person projects.

Quote:Advanced merging: local branches, rebasing, and cherry-picking are things I had no idea I needed until I had them.

I can't even imagine what cherry-picking is in this context. Rebasing is addressed above. I've still yet to see the need for any branching, let alone locally. It doesn't really suit how I work, and I tend to be really careful about merges anyway (even to the point of manually reviewing successful conflict-free automatic merges) so I don't see how the branching helps - if I figure out that I've taken a wrong turn, I figure out what version I started going wrong with, recover it, and fish out the good bits needed to fix the mess.

It isn't pretty, but if there's really a better way, I'd appreciate an example rather than speculation. :)

I would have to recommend Git over everything else