Some time ago I complained [1] about troubles using Git
on a project with high ratio of non-programmers.
Since then, a conclusion was made: Git is too complex.
While Git provides many nice advanced stuff, its simplest
workflow isn't simple enough.
So we examined other options:
* Splitting project in two repos (Git + SVN). It was
thought to be the worst idea because we lost commit
atomicity
* Use GitHub SVN integration [2]. Rejected due to security
considerations: our closed-source project isn't allowed to be
hosted outside.
* Use GitHub Enterprise: rejected due to pricing
* Use SubGit [3]: rejected because of its architecture.
Then, a lost'n'forgotten git_svn_server [4] was found. After playing
with it, we found out that its approach can work, though several
decisions (Python and extensive forking of `git`) made it very slow.
So we thought "we're programmers, after all".
And that's when *git-as-svn* [5] was born. It is a daemon that sits
on top of Git repository and talks svn:// protocol.
Features supported:
* checkout/update
* log
* blame
* commit (!)
* rename detection (though a bit slow yet)
* svn:eol-style
* Git pre-receive hooks
* simple or LDAP authentication
* partial checkout
* sparse working copy (svn --depth/--set-depth)
* git submodules
Current limitations:
* Only a single Git branch from a single repository
* Needs at least one commit in Git
* Parses whole history on startup and doesn't cache it anywhere
* You must not do 'inverted merges'. Old HEAD must be reachable from
new HEAD by first-parent traversal.
[1]: http://marc.info/?l=git&m=139866660018802
[2]: https://help.github.com/articles/support-for-subversion-clients
[3]: http://subgit.com/
[4]: http://git.q42.co.uk/git_svn_server.git
[5]: https://github.com/bozaro/git-as-svn/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html