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.

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.

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.

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?

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.

In both Mercurial and git, the merging programs can be customized because they are essentially scripts operating on top of the base repository interface, though git recently had most of them ported to C from Perl.

In theory, it would be possible to write replacement merging programs. In reality, it just isn't worth it most of the time. Merging algorithms can get pretty complex, especially for revlog-based tracking (which Mercurial uses). Combined with the high number of edge case algorithms added to merging programs to help make merging easier, it would be pointless to write a new merging program. However, extending the existing merging programs is a far more realistic option and it has been done from time to time.

Going by the first post and what I've heard elsewhere, I'm being given the impression that Mercurial support is better on Windows and Git support is better elsewhere. So I guess it's ultimately a matter of which platform do you wish to support more.

If the performance bottleneck for SVN is the result of the web interface and not the VCS itself, why not use both Git and Hg and attach the web interface to the lighter of the two sides?http://hg-git.github.com/