[Andlabs]

Really? What do you mean by complicated? The minimal I can think of is

CODE

git init # new repo
OR
git pull # grab new changes from a server

git add <files>
git status # prints info
git commit -a # not sure what the -a means...
git push # push up to a server

# branching
git branch <newbranch>
git checkout <branchname>

This post has been edited by Andlabs: 19 June 2011 - 04:16 PM

[flamewing]

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.

[Andlabs]

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?

This post has been edited by Andlabs: 19 June 2011 - 04:36 PM

[Conan Kudo]

Really? What do you mean by complicated? The minimal I can think of is

CODE

git init # new repo
OR
git pull # grab new changes from a server

git add <files>
git status # prints info
git commit -a # not sure what the -a means...
git push # push up to a server

# branching
git branch <newbranch>
git checkout <branchname>

As for Mercurial, the equivalent commands are:

CODE

hg init # new repo
OR
hg pull # grab new changes from a server

hg add <files> # add files for versioning
hg remove <files> # remove files for versioning
hg addremove # Removes files marked as missing from versioning and adds any new files not already marked for versioning
hg status # prints info about working repository
hg commit -m <commit message> # -m switch lets you add a descriptive message about the commit without making a text editor appear
hg push # push up to a server

# branching
hg branch <newbranch> # creates a branch from top commit
hg pull # Pull from server like normal to check out code
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.

This post has been edited by Conan Kudo: 19 June 2011 - 05:11 PM

[Overlord]

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.

[Andlabs]

If you don't use branches, you don't worry about merging at all; just keep doing the commit/push and pull. If you are on branches, then

CODE

git checkout [branch to merge into]
git merge [branch to merge]

is all you need to do, and git (and Mercurial — but I've never used it so IDK) are usually better at doing merging than svn (which is why your worker friends call it sucking cock).

[Hendricks 266]

Aren't the merging programs separate or can't they be customized?

[Conan Kudo]

Aren't the merging programs separate or can't they be customized?

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.

This post has been edited by Conan Kudo: 20 June 2011 - 10:59 PM

[Scarred Sun]

Given that this topic has died, can we at least narrow things down? I'd prefer Mercurial simply because it'd be easier to transition to.

Is there any major argument for Git specifically over hg?

[Sik]

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.

[MainMemory]

I'd choose Hg, since I develop programs on Windows, for Windows.
And I found a library so I can rewrite my IRC bot.

[Techokami]

Git, because more people voted for it in the poll above.

[MainMemory]

Among people that actually commit to the SVN: Andlabs, Flamewing, and Hivebrain don't care; Scarred Sun and I want Hg.

This post has been edited by MainMemory: 04 July 2011 - 02:03 PM

[Spanner]

Not that it's going to happen, how about a poll with Git and Hg being the sole options? It'll force the SVN users to make a choice, or just abstain from voting. Probably won't work.

Also, still going down on Hg here.

EDIT: Now that I looked at the poll again, I guess my suggestion is really pointless based on only 4 people wanting to stay with SVN.

This post has been edited by SOTI: 04 July 2011 - 04:19 PM

[sonicblur]

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/