3 ms·
They should use git-svn. using a new version with a few new features of an existing tool (svn) is always an easier sell than using two new tools (git, git-svn)
by WorkerBee 17y ago
They should use git-svn.
using a new version with a few new features of an existing tool (svn) is always an easier sell than using two new tools (git, git-svn) as well, especially when one (git) has a reputation as being very complex, and the other (git-svn) looks like a hack to glue two different systems together.
- cookiecaper 17y agoWell, the thing about git-svn is no one has to know you're using it. The commits look just like they were submitted by SVN. You don't have to sell git or git-svn to anyone. Everyone can keep using SVN, and you can use git, and there would be no issue or problem here at all.
- jrockway 17y agoIt's more fun to spend your free time copying git-svn's features and implementing them in Subversion. Or something. Personally, I would find it more useful to sit around and watch paint peel off my wall. But then again, I didn't write a book about why open source projects should have 100-message-long votes on every line of code to be added to the project... so I clearly don't "get it".
- WorkerBee 17y agoIt's more fun to spend your free time copying git-svn's features and implementing them in Subversion. Or something. For most of us, no. For the SVN team, other forces are at work - I'd say familiarity of the code and desire for their baby to stay relevant are big ones.
- WorkerBee 17y agoYou don't have to sell git or git-svn to anyone. It has to be sold to me (or your typical departmental svn user). I do spend time learning new tools, but that time is limited, so I'm less likely to spend it on something that has the potential drawbacks that I raised. FWIW, yes, I am trying out git on the side. That use of time looks worthwhile.