On Thu, Sep 20, 2012 at 2:31 AM, Andreas Krey <a.krey_at_gmx.de> wrote:
> On Thu, 20 Sep 2012 00:13:45 +0000, Nico Kadel-Garcia wrote:
> ....
>> Java has its uses. Replacing a full-blown, fully implemented C++
>> codebase where the maintainers, who also set the API's, are all
>> working in C++ means entirely different models of file handling,
>> memory management, and maintaining compatibility with a dynamic and
>> evolving codebase, in another language.....
>
> Sorry, but this is just preemptive bad-mouting. The problem isn't that
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" ? 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.
I'm looking into your docs. That bi-directional, behind the scenes,
2-way communication is *scary*. And you're forcing modifiation of the
hook scripts to support this feature set. That would seem to be
*begging* for a failed hook script to leave the repositories out of
sync. It's necessarily asynchronous, and you may have thought out all
the potential issues, but who the heck could tell? It's closed
source!!!!!
> there is no good good implementation of an svn server. The problem is that
> the people working on that implementation aren't going to offer any path
> that would enable other to integrate a git view on the repository. Heck,
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
> they don't even offer a specified network protocol and insist that
> *clients* use the C library.
That's not a subject I've personally gotten into. On thought, you have
a point: well worth separate review. But that's part of the problem
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?
> So the only way to have a server that is viewable via git and via svn is
> to rewrite the server. (Which is also good because the svn repo structure
> is, well, suboptimal even for its own pourposes.) And there is obviously
> enough public interest/suffering that subgit isn't even the first project
> to do so - see svnhub.com.
In theory, understandable. But Andreas, SubGit is closed source!!!!!
Subversion has really, really benefited from the open source licenses.
(I'd have preferred GPL to Apache to help prevent that kind of fork,
but it certainly wasn't my call.)
There are things that would benefit from simultaneous Subversion/Git
client access. For example, I'd *love* to use one client for people
who have to access both old Subversion repositories at Sourceforge,
and git repos at github.com. (I'm publishing the SRPM building tools
for Subversion at Github: it's actually a bit embarrassing, but I
really need the disconnected development.)
> 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 12:36:37 CEST