o_O
But I actually mean … figure out how to do the equivalent of a Mercurial/Git “Pull” on a Subversion branch :( I realize you can do it with a merge, but the process seems to be both messy and unreliable.
We have a whole bunch of branches running these days, and it’s getting messy, not least because Subversion “branches” are part of the repository file system and not part of the revision metadata.
Some time in the last two weeks, I pulled some code from somewhere, made some changes, and dispatched them to the author for review.
Then I scratched my head. I’d just used git.
‘Neato’.
For the last 10 odd years, the game’s data components have been kept in Visual Source Safe. VSS is bad, m’kay. Like any piece of software, it has its merits, especially for a very small team working on a very simple project. I’m not going to turn this into an anti-VSS pejorative tho.
Moving from VSS to Subversion (and then possibly Mercurial) varies in complexity depending on your repository. Ours is ten years old and contains multiple projects, which have danced around the directory tree.
On Friday I used Mercurial‘s built-in repository conversion tool to build a Mercurial repository from Subversion 1.30 branch. Went home, cloned that to my Linux and Windows boxes and I’ve been tinkering over the weekend.
With the inotify extension, it’s really zipping under Linux; especially with atime changes disabled.
And I notice that I’m very quickly falling back into the habit of early commits.
The only bottleneck in the system is that the master repository is on a Windows Server 2003 share, and cloning/pulling/pushing are a little slow. I suspect that I need to look into setting up hgservice or something.
But if we do switch to Mercurial, I think we’ll probably set it up alongside Trac (which I increasingly dislike) or Redmine or something: Trac development seems somewhat bumbling, Redmine is generally nicer but it has rude rough edges – e.g. the forum system is kinda noddy. I will probably like Redmine more when I quit trying to integrate it to our Windows domain logins and use our game-database logins like we do with Trac right now.
This is in response to Drave and Xiper’s questions about my nixing of Git as an option for a replacement version control system.
“Git” is an incredibly popular distributed version control system originally developed by Linus Torvalds, creator of Linux. The fact that it is used by the Linux Kernel development team has given it a firmly established base in Linux development. Add in the “github” project hosting service and it has stealthed into the position of dominant “revision tool thingy” that RCS once held.
“Mercurial” is another popular distributed version control system, lurking in the shadows.
So why did I nix Git and start looking more at Mercurial?
1.31 (or the lack thereof, as yet) has been almost as frustrating for us as it has for our players. It is likely to become known as the “if I’d known that” patch.
I’ve been wholly mired in cell host performance issues for a while, stuck in the maw of code that I really, really, really hate. Code that resists or springs a leak at every turn. It is the code that any sober refactorer would say rewrite to.
But it’s not just some subsystem, or some corner of code. It’s the fundamental basis for the cell host.
6 weeks with SVN, 500 revisions. Actually, if you deduct “structural” revisions and revisions in branches it trims down to 422 revisions. The cool part is that little window in the bottom right of the screen. If you’re about to break code on a new project and you are thinking about adding automated builds/tests … do not do it later. Every character of code is an extra ounce of pain when you “get round to it”.
If you’re using Subversion and you get a problem between two branches with “inconsistent line endings” you may be in for a world of hurt.
I really didn’t think this would happen so quickly. When you’ve been fitting spits and spots of systems together over 6 years towards a goal, you build up an overly active awareness of how much is involved. You’re overly inclined to fill in variables. I knew that the host was easy enough to build, and I’d scripted the mac build for Gophur, so I knew that wasn’t hairy. Recently I’d come to know that now the client and host source is all in one repository I can match source revisions. But, when I tried to put it all together, along with scripting it under Windows … Pop. I think my head just exploded, is that my amygdala on your lapel?
The key to it all was VSoft’s FinalBuilder. There are many build tools, but FinalBuilder is a basically a graphical scripting language / scripting language assembly tool the likes of which you expect from old Amiga tool sets or the Mac. These geniuses of it is delivering the power an old scripting hack like me only images getting from Perl/Python/Ruby/JavaScript/Rexx in a graphical interface.
Generally finding the switch from Visual Source Safe to SVN a boon, but there are definitely some areas where it’s weaker than you’d expect. In particular, we’re running into a few simple ball breakers:
Line Endings. Oh. My. God. When we populated the repository, we didn’t even think about this. Get this, using the Microsoft version control solution it wasn’t an issue. Ha – who’d think the first point for VSS vs Open Source RCS would be a cross-platform issue? (Anyone with coins inserted in their brain meter)
So, none of our files have svn:eol-style native. That’s the fix. But if I svn propset svn:eol-style native */*.cpp */*.h there’s just one minor itty bitty niggle: it changes every line in every file completely destroying history and blame.
kfsone's pittance 
Recent Comments