[almost OT] version control

[imbaczek]

I watched this http://www.youtube.com/watch?v=4XpnKHJAok8 yesterday and I'm sold. I'd advocate switching to git right away if it worked on Windows but it doesn't, so maybe we could consider switching to Mercurial, which Linus commented positively about (and that says something, but you've got to watch the video to understand that.)

Why I post here - with all the talks about branching (which is cheap in svn but nobody cares, merging is something to care about) and giant patches submitted to mantis (Victor's, KDR's), changing the workflow from commits to changesets ("a commit of commits") could visibly make merging stuff easier.

just food for thought. watch the video, it's worth it, and quite funny as an added bonus.

[Agon]

Git can run on Windows with cygwin.
And there are web interfaces available and projects to support Windows.
Look at: http://en.wikipedia.org/wiki/Git_%28software%29
The features of Git sounds very good. If my vote counts I vote for take git!

[imbaczek]

With git on cygwin, the problem is cygwin. It's dog slow, so much that using git will be painful (using other stuff is painfull, didn't try git, but judging from its heavy use of the filesystem, it's not going to be pretty.)

[jcnossen]

There is also monotone, which I've read has roughly the same feature set as git, only slower.
Also it works on windows, and doesn't require python or cygwin.

The bad part is that it doesn't have a nice windows GUI either

[imbaczek]

I looked around and there's also bzr (bazaar-ng.org), ubuntu/canonical use this and it looks quite good. There's also TortoiseBzr and trac+bzr. Sounds promising.

edit: I also managed to use mingw-git to checkout git itself and compile it. Yes, on windows, yes, without cygwin. Neat. edit2: And gitk works. I'm in love.

[malric]

I watched about half of the video, and even if many things sounded nice (have all the history available while traveling for example) it sounded like the system is still centralized but instead of depending on a server it depends on a person. In the linux kernel case this is fine, there is Linus and everybody is using his repository.

I do not follow that closely the development of spring so I can't tell but for me it sounds it is a bit more overhead for some flexibility (which is not necessary usefull).

He states many times that branch merging is a pain etc. I modified gcc 4.1 and I merged the changes from gcc 4.1 to 4.2.1 into my repository, and I had only 1 conflict, solved in less than 1 minute, and voila. Maybe I didn't make that many modifications to have problems.....

So it would be interesting to know what the other developers think - about what features they need. (I like using new software from time to time, but sometimes you have to ask if what you have is not enough...).

[jcnossen]

The ability to make many local branches sounds very appealing to me. Linus also mentions this that when you need to make a branch on a public server then you have to deal with branch namespaces, which can be annoying if you just want to test some stuff.

[Tobi]

Personally I especially noted the lack of the 'who should have commit access' problem. I think not having to deal with that for Spring would be ideal wrt stuff like lua widgets, zwzsg's KP installer etc, just merge in the branches for good stuff and voila, no need to consider whether someone made a one time contribution (no need for commit access) or is going to contribute more (candidate for commit access). Also no need to mess with patches for anyone, easier to cherrypick (there's even git cherrypick) commits if only a part is good enough to apply, etc.

The branching namespace is only a minor thing in my opinion but better merging seems great, especially since it keeps track of all history, not just the history in the current branch as in SVN. Also the fact that it remembers what already has been merged is an improvement, since with SVN you need to look up old log messages to figure out where to start your merge.

Also while reading some of the git documentation I noticed it has lots of features already that I have just hacked onto subversion for Spring, or have been thinking about hacking them onto subversion (for example, the git bisect function, to find a broken branch using a binary search: I do this a bit scripted (build a range of revisions) but mostly manually using SVN).

I have worked a bit in the past with bazaar-ng, but back then I didn't really like it. However, I didn't realize this commit access advantage (and had no reason to bother about that anyway), and bazaar-ng was still in early stages, so my opinion on it may be a bit biased.

I am sure I will give git a try soonish. If these git<->svn things work as well as some people want you to believe they do, I might even start using it for merging stuff in Spring SVN repository.

[imbaczek]

Ultra-cheap easily mergable local branches (that is, not having to clone the whole repo to do a branch) makes me feel warm and fuzzy. Like Linus said: "In svn, branches are a O(1) operation. Nobody cares. Merging is what it's all about."

Speed. Even on mingw32 it's faster than svn (I've got a temporary svn of spring mirrored in git at git://neoteric.pl:9994/spring - that's a linux box, but I cloned that branch on mingw). There's a problem with mingwgit that git-svn doesn't work, but Linux devs can clone this and keep up to date with svn (and even commit to svn) after reading one or two guides and FAQs.

Offline commits and changesets - that is, if you pull from someone, you don't get a one huge commit, but several small ones. There are tools that allow you to simulate that behaviour (stg). Also, when the central server is down, you still can commit AND see the history. BTW, gitk is win.

I for example see immediate use for easy branches:
- I'd like to hack on changing the VFS layer to physfs.
- Someone wants to hack on the netcode.
- KDR did a big and possibly intrusive weapons patch, which has to be updated because it suffers from
- Tobi wants to do code cleanups.
- jc doesn't want to fix sm3 but maybe he'd want to if he could have a sane branch.

There's no reason for all this stuff to be in the central server, since it's all experimental work.

Because of immaturity of git on mingw I'd still consider hg or bzr (especially that bzr is getting faster and is the easiest to use.) svn is a thing of the past IMHO. There's only one thing I'd miss, that's fisheye - but other VCSes have similar free options.

PS Tobi: bzr is on version 0.18 stable and 0.90 release candidate. I didn't like bzr either when I played with 0.12 and 0.15, but it really starts looking neat.

[AF]

With moves by people to put stuff into svn we're already seeing some users have issues getting stuff out of svn under windows and figure out how to sue ti to begin with even with programs like tortoise SVN, and imo this is a drain on our pool of contributors and discourages new people who arent already experienced from learning and contributing.

So whatever system we use we need it to be very clear for newer windows users. If its great under linux thats fine as long as its great under windows too.

[imbaczek]

I don't believe that VCS is a big obstacle, it's got to be set up once and then it's there. If somebody wants access to the source for whatever reason, he should be smart enough to use any sane software required to get it (git is not yet sane for windows, but bzr and hg are very good.)

[Dragon45]

I watched about half of the video, and even if many things sounded nice (have all the history available while traveling for example) it sounded like the system is still centralized but instead of depending on a server it depends on a person. In the linux kernel case this is fine, there is Linus and everybody is using his repository.

Not at all. Watch the whole video. git uses the same web of trust notion that's common in many other security and networking schemes (PGP f.ex).

Basically, what happens "behind the scenes" is completely decentralized, with patches being pulled from one dev (or even a casual dev to another) via the aforementioned web of trust. The way he's selling it, since its decentralized, it *seems* that your own little "dev server" is automatically or simply set up with git, and pulling/pushing deltas is simply done.

What you're talking about is different; you're talking about how the end patch gets from the developer to the user. That's a whole different issue altogether, and is seperate of source code management. In the case of spring, all of the devs would basically have the same master branch anyway, and one of them would make an update. Your concern is basically a non-issue. Its more politics and less technology.

[Tobi]

With moves by people to put stuff into svn we're already seeing some users have issues getting stuff out of svn under windows and figure out how to sue ti to begin with even with programs like tortoise SVN, and imo this is a drain on our pool of contributors and discourages new people who arent already experienced from learning and contributing.

So whatever system we use we need it to be very clear for newer windows users. If its great under linux thats fine as long as its great under windows too.

With any VCS you can set up something so a reasonably recent source is available in zip or tarball. Just put a big red warning sign next to it telling them it will give them a huge headache once they want to make a patch of it.

I think convenience for actual contributors and developers is more important then noob friendlyness for people who don't even know what a version control system is. Would you rather have 5 noob developers because all experienced developers are scared away by the outdated version control system, or 5 experienced developers at the cost of some noob developers that are scared away because you take advantage of new technology?

That said I can imagine git being a bit of a pain on windows (seeing the UNIX design philosophy back in it), though I already like it on Linux

Anyway, I can imagine that we'd get rid off the monolithic SVN thing too in that case, I'm not too fond of that anymore. Or maybe just use a better source control system on the engine, and keep people/projects who can live with SVN in SVN

EDIT: Mark Shuttleworth has some interesting stuff in his blog too, especially about how bzr handles renaming, even of directories, perfectly, and how git does not.
http://www.markshuttleworth.com/archives/123

OTOH, git claims to be able to track code that moves from one file to another using it's heuristics (ie. if you split a file, combine two files into one, move a function from one file to another, etc.).

[imbaczek]

He's got a lot of interesting entries on VCSes. Some good reads.

BTW, since bzr-svn doesn't like SSL, could someone set up a simple http/svnserve read-only repo so I could pull and play around?

[Tobi]

I am uploading two dumpfiles to here as I write this (I don't really have time to set up a repository atm), the upload will take approximately an hour. The md5sums and file sizes are:

Code: Select all

97f6fea76c93a853da7dbf8a2a3691e5  spring-r4046.svndmp.bz2  (168 M)
c246345f65a5b9aa061277349c0205ca  spring-r4047-4235.svndmp.bz2 (12 M)

You can use these to set up a test repository for yourself (and access it using file://), or poke someone like heze to set up a test repo

[YokoZar]

We use GIT for wine at winehq, and it's been amazing since we switched away from svn. You're free to poach any of the instructions there. http://winehq.org/site/git

There are some old modules (eg the webpage) that are still in CVS, but not many people develop these independently so it doesn't really matter if we switch them. This is not the case with Spring, which has many different parts (AI, AI intreface in the game, lobby, etc) that can all potentially interact with one another in exactly the way that GIT is designed for.

[imbaczek]

Ah, fantastic.

I'm playing around with bzr visualize and it's not as good as gitk, but not that bad (no color diffs and poor searching.) Also, it seems that we've got almost 10k files in the repo, I think it's the upper limit of what bzr can efficiently handle - but only slightly more than 3k is really engine related, so some splitting could be in order no matter what VCS we switch to.

IMHO bzr will be a good choice now and converting to git when it is finally easy to use under Windows won't be a problem. I somehow like it better than hg, but will happily use either.

[Tim Blokdijk]

I don't know about distributed version control.
How would this work for the site?
Do I have to stay a central person for the site? I don't like to merge patches each time someone has done a commit to his or here branch.
I have zero hands on experience with this so how would the (my) work flow be?

[imbaczek]

Actually, it'd be easier for you and for the devs. You'd get your own repository, but you'd use that only to brag about something you've finished and pushed out; all your work would be done in small chunks on your own machine.

If somebody wanted to change something, he'd pull your public tree, make changes and ask you to pull or send you patches, which you could examine on a separate branch, so they don't interfere with your current work. No differences on the basic level, except it's a bit easier to share stuff.


BTW this short patch against bzr-svn allows you to import bz2-compressed dumps:

Code: Select all

=== modified file 'convert.py'
--- convert.py	2007-08-09 14:54:13 +0000
+++ convert.py	2007-08-21 22:20:14 +0000
@@ -24,6 +24,7 @@
 from format import get_rich_root_format
 
 import svn.core, svn.repos
+import bz2
 
 def transport_makedirs(transport, location_url):
     """Create missing directories.
@@ -61,7 +62,10 @@
     from cStringIO import StringIO
     repos = svn.repos.svn_repos_create(outputdir, '', '', None, None)
     try:
-        file = open(dumpfile)
+        if dumpfile.endswith('.bz2'):
+            file = bz2.BZ2File(dumpfile)
+        else:
+            file = open(dumpfile)
         svn.repos.load_fs2(repos, file, StringIO(), 
                 svn.repos.load_uuid_default, '', 0, 0, None)
     except svn.core.SubversionException, (svn.core.SVN_ERR_STREAM_MALFORMED_DATA, _):

[Dragon45]

So i take it git/decentralized SCM is the new order of the day (hoping it is).

And uh, command engine should use it as well... (pretty please?)

Btw if you read the talk, you'll see that they did tests with 100,000 files and merges were blazing fast (barely a second, if i recall).


<it be crazy idea tiem now?>
Why don't the website redesigners put the sites under some decentralized SCM and we can all play with it at all?

Overall it seems like more of a wiki-style approach (Shuttleworth's words, not mine), and it seems to be really useful on a practical level.