On Thu, 20 Sep 2012 06:36:02 +0000, Nico Kadel-Garcia wrote:
...
>
> I think it's justified paranoia, due to concerns about "how are you
> ever going to keep this reliably in sync with upstream Subversion
> repository features" ?
Like, not at all? (Note: I'm not affiliated with either github
or subgit and don't talk for anybody but me.) 1.8 can't afford
to drop wire-compatibility with older clients anytime soon,
and the availablility of anything that can serve git and svn
clients will basically make any more svn updates unneeded.
> Subversion 1.8 is due out soon: and the "merge"
> technology is due for serious revision. Previous major releases of
> Subversion, with which I'm far more familiar than git, have included
> all sorts of desirable feature changes such as the switch from default
> Berkeley DB to FSFS, which seemed a great idea.
That particular switch really shoudn't affekt wire protocol. :-)
> I'm looking into your docs. That bi-directional, behind the scenes,
> 2-way communication is *scary*.
Not mine. What you say sounds more like a marriage of the oritinal
servers by hook scripts, now a new server.
...
> It's closed source!!!!!
That's my personal reason not to look into that. :-) If I'd ever
go to design something along these lines, I'd forgo the full
svn compat and offer only the basic operations for svn clients, so
eclipse users and the like are happy, and do the rest on the git level.
Especially merging.
Im my opinion svn is simply outdated for the types of data I have to deal
with (that is, repos that are not going into the gigabytes range), and
the only thing that keeps people from massive migration is the need to
to interoperate old scripting/tools and the reluctant people who don't
actually care much for vesion control and are happy with committing
from time to time. As long as the latter chain 'us' to an svn server a
migration would be painful. As soon as there is a server that works on
git repos and can reasonably talk svn, a lot of switching will occur,
as a migration doesn't need to pull them along all the way at once anymore.
Perhaps I should put up a kickstarter? :-)
...
> That.... would be a lot of work for a limited benefit when the
> "git-svn" client tool works pretty well. Given that this toolkit
> already exists, it's the client access for Subversion clients to
No, git-svn doesn't unchain you from the svn server, nor can you ever
think of redoing your build/deploy in git terms. Most importantly,
you're chained to svn's merging - here we begin to check nontrivial
merges by trying them in git/git-svn and then seeing whether svn gives
us the same results.
...
> here! By keeping the software an integrated codebase for clients and
> servers, they're able to make protocol changes that you'll be forced
> to keep up with in an entirely distinct codebase. How can you *test*
> that robustly?
That is just shifting the problem. Either you have an API that you can't
just modify, or you consider the wire protocol your API, and either way
you have to be backwards-compatible and need something to test on that
level. (Besides in my opinion the wire protocol is only that complex
because you don't replicate - moving whole commits is easier than doing
all the commands remotely.)
> In theory, understandable. But Andreas, SubGit is closed source!!!!!
> Subversion has really, really benefited from the open source licenses.
Strong Ack. I wouldn't even look into github's svn access for serious
stuff for the same reason.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Received on 2012-09-20 13:36:07 CEST