Comment by scotty79

3 months ago

After years of using git I got back to svn.

Svn has one great feature, you can checkout (clone) repo partially.

This way I can keep all my experiments in a single remote repo and easily pull any part of any project locally wherever I want.

I don't really care about branching in svn. If I want to try variants of some code I still use git with multiple branches.

I'm not sure what I would prefer for a team project. I'm sure svn got decent merging.

> After years of using git I got back to svn

You get the best of both worlds--a sane set of commands and a distributed version control system--by using Mercurial [1].

Checking Status: SVN: svn status Mercurial: hg status

Adding Files: SVN: svn add <filename> Mercurial: hg add <filename>

Committing Changes: SVN: svn commit -m "Commit message" (commits changes directly to the central repository) Mercurial: hg commit -m "Commit message" (commits changes to the local repository) and hg push (sends local commits to a remote repository)

Deleting/Removing Files: SVN: svn delete <filename> or svn remove <filename> Mercurial: hg remove <filename> or hg rm <filename>

Viewing History: SVN: svn log Mercurial: hg log

Viewing Differences: SVN: svn diff Mercurial: hg diff

Branching: SVN: svn copy <source_URL> <destination_URL> (creates a branch by copying a directory in the repository) Mercurial: hg branch <branchname> (creates a new named branch within the repository)

Reverting Changes: SVN: svn revert <filename> (reverts local modifications) or svn merge -r <revision>:<revision> <URL> (for more complex reverts) Mercurial: hg revert <filename> (reverts local modifications) or hg backout <changeset> (to undo a specific commit)

[1]: https://www.mercurial-scm.org

One really nice thing about a distributed version control system is that it lets me as a developer make commits to track my work without having to push them to a central location and pollute the global commit history of the repository. I can modify my commit history (to clean it up and remove all of my failed experiments, for example) before I publish it, so to speak. Or I can completely remove my commits without publishing at all if what I was trying didn't pan out.

I think git can do partial checkout these days, you can even filter which parts of the history to store locally, like download all commits, but not the file content for them, and dynamically load them when needed.

> I'm sure svn got decent merging.

That's definitely not my experience. SVN has merging, but I've found it extremely frustrating in a team context.

  • When did you experience it last time? I remember it being bad, but it was before git was created.

    • Last year, unfortunately. Most modern utilities, even svn-to-git migration utilities, have been abandoned now that git has become the de-facto standard and everyone who can reasonably be expected to switch to git has done so already.