don't click here

Replacing svn with git/Mercurial

Discussion in 'Engineering & Reverse Engineering' started by FraGag, Jun 16, 2011.

Switch to git, switch to Mercurial (hg), or stay with Subversion (svn)?

  1. Switch to git

    5 vote(s)
    55.6%
  2. Switch to Mercurial (hg)

    2 vote(s)
    22.2%
  3. Stay with Subversion (svn)

    2 vote(s)
    22.2%
  1. FraGag

    FraGag

    Tech Member
    If you're reading this, you probably know what we couldn't commit to the svn repository for a while. Instead of figuring out how to keep the svn and WebSVN working all the time, I suggested that we switch to either git or Mercurial (hg). git and Mercurial use similar concepts that are quite different from svn, so there would be an adaptation period for those who have never used them, but then again, most of us probably learned svn through this project. :P

    Both git and Mercurial are distributed version control systems. While with svn, the repository was stored on a server and all you had was a working copy, with DVCSes everybody has their own repository. This means that you can make local changes on your computer, commit them to your local repository to build a history, then you can push your changes to a central repository when you're ready to share them. You could also keep using git or Mercurial for your hack by committing your changes to your local repository without ever pushing them to the central repository. By committing regularly, you keep a version history and don't need to make manual back-ups in case you screw up with your hack; however, you'd still have to back up your repository or push it to a remote location in case your hard disk fails. (Technically, it would have been possible to use a local svn repository, but not with Retro's svn repository history.) Also, by building your hack in a repository, you can later pull changes made to Retro's repository and integrate them in your hack; if you edit very little code in your hack, the changes will most of the time be merged automatically.

    And hopefully, the web access clients for git and Mercurial don't suck as much as WebSVN. :P

    To help you make a choice between git and Mercurial, should you be asking yourself that question, here are some notes about them:
    • git is faster than Mercurial.
    • On Windows, git doesn't handle characters outside of ASCII (characters 0 to 127, for those who think ASCII is more than that) correctly in file names and commit messages: it reads them using the system's ANSI code page (e.g. CP1252) but then tries to interpret the bytes as UTF-8, which fails. This means that such characters would probably be rendered as ? or ?. Mercurial also has this problem, but it can be fixed for the most part by using the fixutf8 extension (the only issue is when you try to create or clone a repository in a directory that contains characters outside of ASCII, in which case the repository will not be created correctly).
      EDIT: GerbilSoft made me notice utf8-git-on-windows, which aims to fix this problem.
    • git identifies revisions using a SHA-1 hash. Unlike svn, revision identifiers are not sequential. This wouldn't make sense anyway, because it is possible to create revisions in separate repositories and merge them together later on. Mercurial does this too, but it also uses sequential revisions numbers. However, these sequential numbers are only relevant in a specific repository, so they won't necessarily make sense in other repositories, even if they're all based on the same source repository.
    • Both have graphical clients on Windows. TortoiseGit is build from TortoiseSVN and tries to make git work like svn, which isn't necessarily a good thing... TortoiseHg, on the other hand, is completely different; it's really made for Mercurial. It's available as a Windows shell extension and as a GNOME/Nautilus extension.
     
  2. Ollie

    Ollie

    DIGGY DIGGY HOLE Member
    Git is the way forward! Would love to see that replace the SVN on here in the future especially if it's hard work to maintain it.
     
  3. Techokami

    Techokami

    For use only on NTSC Genesis systems Researcher
    1,373
    81
    28
    HoleNet!
    Sonic Worlds Next
    Seconding a vote for git.
     
  4. Aerosol

    Aerosol

    Not here. Moderator
    11,163
    573
    93
    Not where I want to be.
    Sonic (?): Coming summer of 2055...?
    My vote probably means squat, but it's going towards git.
     
  5. Conan Kudo

    Conan Kudo

    「真実はいつも一つ!」工藤新一 Member
    478
    1
    18
    I want to put for the case to replace Subversion with Mercurial:

    With the platform diversity of the folks of Sonic Retro, I'd probably say that Mercurial is a better option, since it has been ported to many platforms and handles line endings a bit more gracefully than git does.

    Mercurial is much easier to get a handle on, thanks to the trove of user guides available for it. For example, Hg Init is a tutorial site aimed at helping new VCS users and SVN users understand and get used to Mercurial. There's also a tutorial on Mercurial's official wiki, and a free official book on Mercurial.

    TortoiseHg, after being rewritten to use Qt instead of GTK+, integrates much more cleanly into Windows Explorer than previous versions, and is very good at handling Unicode as well, since Qt has native UTF-8 support. And of course, TortoiseHg has a GNOME/Nautilus module, which no other TortoiseVCS variant has.

    Mercurial requires no daemon program running in the background for the server repository to work, only that the repository configuration files are set properly. Mercurial will also shrink the total size of the repository many times over, because of the way the revlog works. It is also very easy to make a complete SVN import into Mercurial and preserve the entire repository history.

    Mercurial is also quite fast on most platforms it runs on, whereas git unfortunately is not very fast on Windows because it relies heavily on UNIX style forking, which is emulated using either MSYS POSIX library or Cygwin POSIX library. Also, while git has gotten easier to use, it is still more cryptic and confusing than Mercurial.

    Mercurial has been very well tested, with Mozilla/Mozdev, OpenJDK (Java), OpenOffice, OpenIndiana (OpenSolaris fork), Python, WiX, Enano CMS, and others relying on it for their projects, and having excellent reliability. Many of these projects chose Mercurial because it works very well in nearly all environments they develop under, be it Windows, Linux, Mac OS X, Haiku OS, or something else altogether!

    Mercurial also has two free Visual Studio integration add-ins available: VisualHG (for MSVS 2005/2008/2010), and HgSccPackage (for MSVS 2008/2010). Integration with Eclipse, NetBeans, and other IDEs are available as well.

    Some available web interfaces for Mercurial repositories are: phpHgAdmin, hgweb (included in Mercurial), TracMercurial, etc.

    Maven, Redmine, and JIRA already include Mercurial support built-in.
     
  6. Scarred Sun

    Scarred Sun

    Be who you needed when you were younger Administrator
    7,745
    127
    101
    Tower 8 ️
    Welp, this.
    I'm also on team hg for what it's worth.
     
  7. Andlabs

    Andlabs

    「いっきまーす」 Wiki Sysop
    2,175
    1
    0
    Writing my own MD/Genesis sound driver :D
    I don't care what we move to, but two things:

    1) I don't know if we should keep the current folder-based system or split every project into its own repository. Would there be any advantages to either way? I know that if we go the latter, then everyone would only have what they need...
    2) What about tying commits to users? Or is that not going to happen?

    Then you have the problem of sharing code, though I don't know how to resolve that except keep everything together.
     
  8. Scarred Sun

    Scarred Sun

    Be who you needed when you were younger Administrator
    7,745
    127
    101
    Tower 8 ️
    Welp, this.
    Tying commits to users would require us to either come up with some crazy hook that would intergrate with our databases (doubtful) or require every person who wanted to commit to have to ask for an account (annoying.)

    Just saying.
     
  9. flamewing

    flamewing

    Emerald Hunter Tech Member
    1,161
    65
    28
    France
    Sonic Classic Heroes; Sonic 2 Special Stage Editor; Sonic 3&K Heroes (on hold)
    Out of curiosity, is there anything in git or Mercurial that would render them immune to the recent issue(s) we experienced with SVN? If yes, then I fully support the move, but I don't care which VCS is used (git or Mercurial). If git and Mercurial would fare no better, I don't care which VCS is used (git, Mercurial or SVN), and will use whatever is available.
     
  10. Andlabs

    Andlabs

    「いっきまーす」 Wiki Sysop
    2,175
    1
    0
    Writing my own MD/Genesis sound driver :D
    Simple: they're decentralized, so you have a copy of the repository that you can privately commit and then can push up to the server acting as the source. I'm not sure how conflicts are resolved, though...

    Actually, there is no way we can continue to have the everything-in-one-asm-file approach if we go this route without edit conflicts up the ass if people decide to seriously work on these things. Sorry.
     
  11. Spanner

    Spanner

    The Tool Member
    Jumping on the Mercurial bandwagon here. Whilst SVN has been a great advantage to many users here (and I'm not just covering the Retro SVN Project), Hg seems to be the better option compared to sticking with SVN, or jumping to Git. Plus, we need to have a system that can be used by many people, not just some.
     
  12. Conan Kudo

    Conan Kudo

    「真実はいつも一つ!」工藤新一 Member
    478
    1
    18
    In Mercurial, merging is usually done with "hg merge" and it will attempt to automatically merge files unless some edit differs at the same spot in the file being merged. Then Mercurial forces YOU to deal with it instead of having it try to do it and fail and make a horrible mess of things. Git handles it the same way. So does Bzr, and pretty much every other modern VCS developed in the last ten years.

    It's bad development practice to keep everything in one ASM file, so you shouldn't be doing that anyway.

    I'm not sure about git, but Mercurial would fare better because hgweb doesn't actually write humongous cache data all the time. And since there's no daemon running to keep a repository working in Mercurial, there isn't the overhead of another server caching in commits and writing them to the repository. This should also be true for git, but I'm not positive.

    It might not be too difficult. One thing I've found that might help is something called SCM-Manager. It seems to support total user management for repos from the web interface. Its user auth system is extensible, and a plugin could be written to use the Retro user database and allow to specify which users are allowed to log in and push commits.
     
  13. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,735
    334
    63
    SonLVL
    We should be polling the people that actually make commits to the SVN (myself, Andlabs, FraGag, Flamewing, Hivebrain, occasionally some others), because everybody else can use the web frontend if they just want to get the latest disassemblies.

    Personally, I don't care much which way we go.
     
  14. Hivebrain

    Hivebrain

    Administrator
    3,047
    154
    43
    53.4N, 1.5W
    Github
    I prefer whichever is simplest to use, but as long as it's no more complicated than SVN, I don't mind.
     
  15. Overlord

    Overlord

    Now playable in Smash Bros Ultimate Moderator
    19,218
    965
    93
    Long-term happiness
    git & mercurial are BOTH more complicated than SVN from what I've read, and I looked into git as a possible replacement for svn for my own projects. Decided not to in the end. That said, as a single dev I don't need to worry so much about edit conflicts, which is what these two are more designed around...
     
  16. Andlabs

    Andlabs

    「いっきまーす」 Wiki Sysop
    2,175
    1
    0
    Writing my own MD/Genesis sound driver :D
    Really? What do you mean by complicated? The minimal I can think of is

    Code (Text):
    1. git init # new repo
    2. OR
    3. git pull # grab new changes from a server
    4.  
    5. git add <files>
    6. git status # prints info
    7. git commit -a # not sure what the -a means...
    8. git push # push up to a server
    9.  
    10. # branching
    11. git branch <newbranch>
    12. git checkout <branchname>
     
  17. flamewing

    flamewing

    Emerald Hunter Tech Member
    1,161
    65
    28
    France
    Sonic Classic Heroes; Sonic 2 Special Stage Editor; Sonic 3&K Heroes (on hold)
    I agree. As a C++ programmer, I have gotten used to the "1 class per source file" paradigm (even though I don't apply it ruthlessly), but this is harder to implement in an ASM context. In my own hack, I split up the s2.asm in a manner similar to the S1 disassembly, down to the splitting into multiple files of Sonic's and Tails' code; but I know that the latter is not well liked.

    I would vote for restructuring the S1 and S2 disassemblies into a folder structure similar to the S3 disassembly, but also splitting object code into those same folders as their art, but not splitting (say) Sonic's code as is done in the current S1 disassembly.

    FYI, I am putting my vote for "change", but I still don't care about which gets selected.
     
  18. Andlabs

    Andlabs

    「いっきまーす」 Wiki Sysop
    2,175
    1
    0
    Writing my own MD/Genesis sound driver :D
    I was planning on doing this as an experiment (so I'll be hosting this change rather than putting it on the svn) to see how people would like it but didn't get to it this weekend =P Maybe tomorrow?
     
  19. Conan Kudo

    Conan Kudo

    「真実はいつも一つ!」工藤新一 Member
    478
    1
    18
    As for Mercurial, the equivalent commands are:

    Code (Text):
    1. hg init # new repo
    2. OR
    3. hg pull # grab new changes from a server
    4.  
    5. hg add <files> # add files for versioning
    6. hg remove <files> # remove files for versioning
    7. hg addremove # Removes files marked as missing from versioning and adds any new files not already marked for versioning
    8. hg status # prints info about working repository
    9. hg commit -m <commit message> # -m switch lets you add a descriptive message about the commit without making a text editor appear
    10. hg push # push up to a server
    11.  
    12. # branching
    13. hg branch <newbranch> # creates a branch from top commit
    14. hg pull # Pull from server like normal to check out code
    15. hg update -C <branchname> # allows you to switch between branches
    And if you think Mercurial (and/or git, by extension) is more complex than Subversion, read this.
     
  20. Overlord

    Overlord

    Now playable in Smash Bros Ultimate Moderator
    19,218
    965
    93
    Long-term happiness
    My logic on why it's more complicated is SVN basically only has 2 real commands, update and commit. Up and down, that's it. With git/mercurial you enter into the world of merging, demerging, and other wacky shenanigans - like I said, for someone who is the sole developer it's really not worth the hassle. =P

    As I said though, this is going to be for multiple users though, which from what I gather from a friend of mine who uses svn at work with multiple people, SVN chugs cock at. So the initial pain is likely going to be worth it in this instance.