Use git instead of SVN.

[RetroX]

Because it's better.

[luiscubal]

Do you really care?
I mean, will you take advantage of forking, etc.? Are you planning to switch to github? Something like that?

[polygone]

github sucks balls

[RetroX]

Do you really care?
I mean, will you take advantage of forking, etc.? Are you planning to switch to github? Something like that?

No, I'm saying that it would be easier to manage if it were turned into a git repostory.

SVN is terrible to work with.

And yes, forking would enable regular users to contribute changes and test them and then offer them back to the dev team.

[Rusky]

Git will solve actual problems that have already been encountered several times.

For example, as RetroX described, users without commit privileges will be able to work on potential contributions without abandoning version control. Projects like JoshEdit support could be put in a separate branch without killing Ism's working directory (git stash would be helpful here as well). Updates would be much faster and repositories (somewhat ironically) smaller, or at last comparable in size. For Linux developers, the version control tool itself would also be much faster.

Also, if ENIGMA further switched to GitHub, the web interface for viewing changes and files would be improved by about a factor of infinity.

[Josh @ Dreamland]

I thought I replied to this thread.

Switching would bring serious benefit to the tagging system; it takes too fucking long and consistently fails trying to mark the trunk as stable or testing. So huge benefit to be gained.

Difficulty is, everything is already set up in LGM to use SVN for downloading updates, via SVNkit. JGit seems to be what we'd look to for its replacement.

Also, the Wiki install pages all give SVN checkout instructions; those would either need to be replaced or supplemented (in case we want to keep the SVN version current) with the git how-tos.

If either of you are volunteering, I'll be happy to make the switch. I don't speak for Ism.

[RetroX]

I'd be willing to do it.  Or help out, at least.

I can set up a repo here if someone gives me the permissions.

[IsmAvatar]

When I get the chance, I'll start porting the updater to JGit (and/or browse for alternatives to JGit). It's completely self-contained, as can be seen by the method of turning it off (just delete svnkit.jar).

If you guys want to go ahead and start porting ENIGMA's SVN to GIT, whatever that entails, be my guest. It'll make my job easier because then I'll have a working repository to test against.

Unfortunately, while I have a ton of experience with SVN, I only have a tiny bit of experience with GIT, so either I'm going to have to do some learning, or someone else is going to have to be our resident repository expert.

[RetroX]

Unfortunately, while I have a ton of experience with SVN, I only have a tiny bit of experience with GIT, so either I'm going to have to do some learning, or someone else is going to have to be our resident repository expert.

I know loads about git, so, I can tell you want if/when needed. When you're developing on Linux, I recommend looking into gitg; it's an extremely useful commit history visualiser (particularly with branches) and supports mediocre staging/committing.

Essentially, Git works off of unstaged, staged, stashed, and committed changes:

• Unstaged changes are just unversioned file changes.
• Staged changes are the changes that are ready to commit.
• Stashed changes are sort of halfway between unstaged and staged; they work somewhat like stacks.  You can stash changes if you want to keep changes that you've made on hand while returning back to the last versioned state.
• Git operates as a fully local repo with links to other repos. On your own repository, you can commit and uncommit as much as you want, and when you're ready, you can push those changes to another repo. You can also pull changes from said repo. You can technically uncommit on your local repo even if you've pushed changes, but then, you'll have problems when you want to push new changes forward.
• I don't fully understand how SVN's branches work, but git's are essentially "branching" off of an existing commit.  Essentially, what this means is that on your new branch, all changes will be inherited up until a point, and then, you'll only inherit future commits on that branch.  You can merge branches, too.  You can stash changes and switch branches if you want to save your work from another branch while saving your progress on another. From what I've heard of SVN's, those are more of "let's create a repo within a repo and not care about past changes"
• Git also supports cherry-picking, which enables you to pull single commits from one branch onto another.
• Git's version control is object-based, not file-based (like SVN). This means that renames will not bork the entire system, but getting a single file's commit history is slightly more difficult.

Git operates based off of changes and merges a lot better than SVN does.  If you modify the first half of a file in one branch, then the second half in another, git can merge both changes without a problem.  It's only where these changes intersect that it causes problems (such as two branches changing the same line).

There are loads of things that you can actually do with it, but I'll explain them as they're needed rather than all at once.  Plus, you probably know a lot of it.

[IsmAvatar]

SVN's branches are just total copies of one folder to another. This takes up very little space, since it can just say "this is the same as folder X at revision Y". It does actually have the full history behind each file, due to this linking nature. The branch does, however, get out of date if you don't merge the trunk with it, which means you should either regularly merge, or merge before reintegrating.

SVN has actually gotten a lot smarter at merging files, too. Usually you can merge a file with changes on both ends without issue, provided you didn't modify the same line. Every now and then it does get fussy over something silly, though.


Just to clarify what SVN does. I, of course, see loads of benefits to using GIT over SVN, provided I can figure out how to work it.