28 Jul, 2010, Tyche wrote in the 1st comment:
Votes: 0
I'm using subversion and thinking of migrating everything to git.
I formerly used CVS and WinRCS; in fact I still have a lot of code sitting around in WinRCS.
The change from CVS to Subversion was totally painless for me. In fact I like subversion.

Anyone using git? Is is it painless to move from svn to git? Will this old fart have to relearn everything?
Advantages/disadvantages over svn? Good Windows/Apache2.x support?
28 Jul, 2010, Runter wrote in the 2nd comment:
Votes: 0
I use git. I love it. I think with your other experience it would be easy to use.
28 Jul, 2010, ralgith wrote in the 3rd comment:
Votes: 0
I personally am sticking with Subversion. I prefer it server side, though client side they're both the same level of difficulty.

Of course, I also prefer it because Anjuta (my C/C++ IDE) hooks directly into svn repos… I'm not sure if it does git yet or not.
28 Jul, 2010, Lyanic wrote in the 4th comment:
Votes: 0
I use Subversion, as well - mind if I ask why you're thinking of migrating away from it when you say you like it?
28 Jul, 2010, David Haley wrote in the 5th comment:
Votes: 0
Subversion irritates me – it's CVS done right, sure, but the entire paradigm is broken to begin with. Its handling of branches, for instance, is irritating (although it is leagues beyond CVS's utterly terrible handling).

I prefer bzr over git for ease of use, however git is faster. Both are fairly easy to use, though.
28 Jul, 2010, quixadhal wrote in the 6th comment:
Votes: 0
One thing to watch out for in git… it doesn't directly track file renames. Normally this isn't a huge deal, but it can bite ya. It tries to follow renames by matching checksums of objects that were checked in, so if you rename a file and then add/commit, and then modify it, you're good to go. If you both change a file AND rename it on the same commit, git will view it as deleting the old file and creating a new one, losing the change history.

One other minor issue is that it's difficult to create a partial branch. IE: You put your entire MUD into git, and now want to make a repository that omits some directories, but still keeps up to date with the rest. It can be done, but even the folks on nabble who know lots more than I do say it isn't very easy.

Otherwise, I've been having pretty good luck with it so far. It is nice to have the full change history in-place, rather than off in some /var/cache/ hidden location you have to remember to backup. git uses checksums for commit identifiers, rather than version numbers, so be sure you tag commits that are "important", so you can go back to them easily.

I've not yet attempted to do anything clever with branch/merge, so I'll let others speak to that part.
28 Jul, 2010, Tyche wrote in the 7th comment:
Votes: 0
Lyanic said:
I use Subversion, as well - mind if I ask why you're thinking of migrating away from it when you say you like it?


I went to update subversion and the site has been vacated. It's become some sort of part of the Apache project. The people who maintained the Windows binaries and bindings for Ruby and Python in nice zipped packages have apparently left the project. There's links to some corporate sites…

* CollabNet (professionally supported and certified by CollabNet)
* SlikSVN (32- and 64-bit client MSI; maintained by Bert Huijben, SharpSvn project)
* VisualSVN (VisualSVN Server; maintained by VisualSVN)
* WANdisco (professionally supported and certified by WANdisco)

If you go to these sites you'll see installers that have their crap bundled in with subversion, like auto updaters, installing Apache, GUI clients.
So mainly I'm annoyed.

However I note that git seems to be gaining popularity and wanted to gauge the learning curve and differences.
28 Jul, 2010, Tyche wrote in the 8th comment:
Votes: 0
quixadhal said:
One thing to watch out for in git… it doesn't directly track file renames. Normally this isn't a huge deal, but it can bite ya. It tries to follow renames by matching checksums of objects that were checked in, so if you rename a file and then add/commit, and then modify it, you're good to go. If you both change a file AND rename it on the same commit, git will view it as deleting the old file and creating a new one, losing the change history.


That's a good tip.

I think I'll try running a parallel repo in git and see if I can figure it out.
10 Aug, 2010, Sryth wrote in the 9th comment:
Votes: 0
I've used a fair number of version control packages, including bzr, svn and git among others. I prefer git.

I'm curious how the experiment is working out for you?
13 Aug, 2010, Tyche wrote in the 10th comment:
Votes: 0
Sryth said:
I've used a fair number of version control packages, including bzr, svn and git among others. I prefer git.

I'm curious how the experiment is working out for you?


Well I haven't had any problems with it yet. As far as basic usage..creating local repositories and pushing changes.

However, I am having problems configuring it so I can do a remote push to my repository via DAV.
And I'm not exactly sure how to configure security yet.

This is the setup I'm attempting to migrate to: http://repo.sourcery.dyndns.org
16 Aug, 2010, Sryth wrote in the 11th comment:
Votes: 0
Dunno if you've gone through this yet, but the DAV stuff might help.

Remote push via git w/DAV
16 Aug, 2010, Tyche wrote in the 12th comment:
Votes: 0
Sryth said:
Dunno if you've gone through this yet, but the DAV stuff might help.

Remote push via git w/DAV


Thanks. I was unable to get it to work from that, but then I found this: 8-ways-to-share-your-git-repository. For some reason I could not get it to work using the Location directive at all, but I did get it working using Directory.

I'm sort of disappointed in the permissions system. I figured it'd be more advanced than subversion. It's pretty much the same. I was hoping to be able to protect certain branches, like allow all committers to push to a mob branch and only some to the master branch. Anyway it's really not a big deal as I've lived with it using subversion.
17 Aug, 2010, Sryth wrote in the 13th comment:
Votes: 0
Quote
I'm sort of disappointed in the permissions system. I figured it'd be more advanced than subversion. It's pretty much the same. I was hoping to be able to protect certain branches, like allow all committers to push to a mob branch and only some to the master branch. Anyway it's really not a big deal as I've lived with it using subversion.


Yeah, for fine-grain control you have to add something like Gitosis, and many aren't thrilled about that, including myself.
17 Aug, 2010, David Haley wrote in the 14th comment:
Votes: 0
I think that this is an inherent issue with the fact that users are not git users, but file system or DAV users – git (or bzr or svn or …) is not in control of the permission model.
17 Aug, 2010, quixadhal wrote in the 15th comment:
Votes: 0
It's also very difficult to fork a branch that excludes directories already present. For example, if you put your entire MUD into a git repository, you probably want to exclude the player files, log files, and perhaps some areas. Git doesn't really provide a way to do this, although there is a utility to try and work around that as well.
17 Aug, 2010, Tyche wrote in the 16th comment:
Votes: 0
quixadhal said:
It's also very difficult to fork a branch that excludes directories already present. For example, if you put your entire MUD into a git repository, you probably want to exclude the player files, log files, and perhaps some areas. Git doesn't really provide a way to do this, although there is a utility to try and work around that as well.


Doesn't the .gitignore file handle that?
17 Aug, 2010, bbailey wrote in the 17th comment:
Votes: 0
Tyche said:
quixadhal said:
It's also very difficult to fork a branch that excludes directories already present. For example, if you put your entire MUD into a git repository, you probably want to exclude the player files, log files, and perhaps some areas. Git doesn't really provide a way to do this, although there is a utility to try and work around that as well.


Doesn't the .gitignore file handle that?


I believe Quix is referring to sparse checkouts where you may wish to only checkout (or fork, or whatever) /trunk/some/dir rather than the whole repository, where that stuff is already committed to the repository. My solution is to simply not track sensitive files (player data, logs, etc, from the 'live' game) in git in the first place. If you must, then at least keep it on a local branch that you don't export to the rest of the world.

Edit:
To answer the question directly, .gitignore is applicable only to the files that are not already tracked by git. Once a file's committed to the repository, you have to use other means to cope with the existence of or changes to files you don't wish to see.
02 May, 2011, avidal wrote in the 18th comment:
Votes: 0
I've been using git exclusively for over a year now. Before git, I used mercurial for a brief time and though I liked it, I prefer git. Before that, I used subversion for a very long time at work.

I'll be glad to answer any git questions anyone has, and although I'm not a power user, I feel comfortable I can answer most beginner level questions. Also, an excellent resource is the great (free) book that can be read online, Pro Git: http://progit.org/book/

In regards to the permissions questions from earlier in the topic, git by itself does not support permissions like that. Instead, you can use gitolite, which is similar to gitosis, but much more powerful. One thing that gitolite requires, however, is pushing/pulling over ssh, which you may not be comfortable setting up. See http://progit.org/book/ch4-8.html for some basic documentation on setting up gitolite.

Another issue I read about in the thread is cloning everything but world files, or setting them up to not track, etc. My solution to this problem is to implement world/player files as separate repositories that are included in the primary repository as submodules. Submodules need to be pulled/pushed independently of the parent repository and so the risk of accidentally pushing pfile changes during development is mitigated using this method.

About tracking renames: git is very good at handling renames, and I routinely rename/move a file and change it in the same commit and have never encountered an issue with git tracking the rename and the change. I'm sure if you change it too much you'll have a problem, but I haven't encountered that myself.

Finally, the preferred way to host a git repository that other people will collaborate on is over SSH, where everyone uses the same user account (typically git) and access is managed by public key. However, this can be a bit of a pain to setup properly. Git's new smart http method is much easier and only requires a webserver (with a proper user file to limit access). For more information regarding git hosting, check out the Hosting chapter in the Pro Git book: http://progit.org/book/ch4-0.html

[edit] The current Pro Git book was written before the Smart HTTP transport landed in git. For information on using the Smart HTTP transport for read-only and full access to a git repository, see this blog post: http://progit.org/2010/03/04/smart-http....
02 May, 2011, Runter wrote in the 19th comment:
Votes: 0
Quote
Git's new http method is much easier and only requires a webserver (with a proper user file to limit access).


That's what I prefer I think.
02 May, 2011, avidal wrote in the 20th comment:
Votes: 0
Oh, one more thing I'd like to mention. I run redmine on my server and have it wired up for git. If you'd like to try out a hosted git solution without having a public repository on github and without having to set it up yourself (and don't care about strict ACLs on a per-branch/directory basis), I'd be glad to give you a project and make you an admin on my server.

Just head to http://code.beerputer.com and register an account.
0.0/20