[subgit-users-2012] [ANN] SubGit 1.0.0 is released

[Alexander Kitaev]

Hello All,

Our team is proud and delighted to announce SubGit 1.0.0 release!
New version is available for download at SubGit web site at http://subgit.com/

SubGit is a server-side tool for a smooth, stress-free Svn to Git
migration. SubGit lets one to set up a bidirectional Subversion to Git
replication (writable mirror) and thus it allows users to choose
freely between Subversion and Git version control systems.

SubGit is a closed source Java application, which is free for use in
Open Source and Academic projects, as well as in any repository with
up to 10 committers. Besides, there are no limitations on the time you
may evaluate SubGit in commercial or closed source projects.

A few useful links:

SubGit Web Site: http://subgit.com/
SubGit Book: http://subgit.com/book/ - nice illustrated guide that
would help you to install, configure and use SubGit
SubGit Issues Tracker: http://issues.tmatesoft.com/issues/SGT

With best regards,
Alexander Kitaev,
TMate Software,
http://subgit.com/ - Safe Svn to Git Migration!
http://svnkit.com/ - Java [Sub]Versioning Library!
http://hg4j.com/ - Java Mercurial Library!
http://sqljet.com/ - Java SQLite Library!

[Daniel Bell]

Hi Alexander,

Thanks for the update. I just tried downloading the Debian package for
1.0.0, but it looks like the checksum on the website is incorrect. I'm
getting 30e425cd33afe3a1a15b46669ba8d631. Could you please confirm that
the package and checksum are ok?

Thanks

Daniel

> _______________________________________________
> subgit-users mailing list
> subgit...@subgit.com
> http://lists.tmatesoft.com/mailman/listinfo/subgit-users
>

[Semen Vadishev]

Hello Daniel,

Thanks for the heads-up! The download page had invalid MD5 checksums for
both distributions.

I've just checked .zip and .deb files on our build server and on the
server that hosts www.subgit.com; I confirm the following checksums are
valid:

$ md5sum subgit_1.0.0_all.deb subgit-1.0.0.zip
30e425cd33afe3a1a15b46669ba8d631 subgit_1.0.0_all.deb
2a2de35b47218fdfcf78f7d425971c90 subgit-1.0.0.zip

The download page is already fixed.

Thank you,

Semen Vadishev,
TMate Software,
http://subgit.com - git-svn bridge!

[Nico Kadel-Garcia]

On Wed, Sep 19, 2012 at 3:34 PM, Alexander Kitaev <kit...@tmatesoft.com> wrote:
> Hello All,
>
> Our team is proud and delighted to announce SubGit 1.0.0 release!
> New version is available for download at SubGit web site at http://subgit.com/
>
> SubGit is a server-side tool for a smooth, stress-free Svn to Git
> migration. SubGit lets one to set up a bidirectional Subversion to Git
> replication (writable mirror) and thus it allows users to choose
> freely between Subversion and Git version control systems.

Except, of course when it doesn't. The use of OS specific EOL, which
git does not support, and subversion keywords like $Id$ and $Author$,
which git does not support, would seem to me to be an adventure
begging to happen.

> SubGit is a closed source Java application, which is free for use in
> Open Source and Academic projects, as well as in any repository with
> up to 10 committers. Besides, there are no limitations on the time you
> may evaluate SubGit in commercial or closed source projects.

And I'm afraid to say this sounds like a really, really bad idea on
the server side. There are enough inconsistencies in merging
technologies of each system and in the workflow that it *sounds* like
those gods-awful screws that have both flathead slots and Phillips
head crossed slots in them:

> A few useful links:
>
> SubGit Web Site: http://subgit.com/
> SubGit Book: http://subgit.com/book/ - nice illustrated guide that
> would help you to install, configure and use SubGit
> SubGit Issues Tracker: http://issues.tmatesoft.com/issues/SGT
>
> With best regards,
> Alexander Kitaev,
> TMate Software,
> http://subgit.com/ - Safe Svn to Git Migration!
> http://svnkit.com/ - Java [Sub]Versioning Library!
> http://hg4j.com/ - Java Mercurial Library!
> http://sqljet.com/ - Java SQLite Library!

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..... sounds like the very, umm,
"clever" engineer I knew who tried to write a source control system
based on checked out branches having locked files owned by root and
hardlinked to the original code. It sounded like an efficient idea on
paper, but lord, it was painful to clean up after.

[Andreas Krey]

On Thu, 20 Sep 2012 00:13:45 +0000, Nico Kadel-Garcia wrote:
...

> Except, of course when it doesn't. The use of OS specific EOL, which
> git does not support, and subversion keywords like $Id$ and $Author$,
> which git does not support, would seem to me to be an adventure
> begging to happen.

Or like tags, which svn does not support?

You may also want to update on the current git feature set.

...

> "clever" engineer I knew who tried to write a source control system
> based on checked out branches having locked files owned by root and
> hardlinked to the original code. It sounded like an efficient idea on
> paper, but lord, it was painful to clean up after.

That bears a certain similarity with the history of merge support in svn
and the idea of implementing 'move' as 'copy+delete', the bugs caused by
which have still not been sorted out by the API-setting engineers.

Andreas

--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

[Andreas Krey]

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
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,
they don't even offer a specified network protocol and insist that
*clients* use the C library.

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.

[Alexander Kitaev]

Hello Daniel,

Thank you for pointing into this. We've tested and uploaded binaries, but then regenerated web site (without replacing already tested binaries) so checksums were computed for different files.

We'll fix that ASAP, thanks.

On Sep 20, 2012 1:40 AM, "Daniel Bell" <db...@tyro.com> wrote:

Hi Alexander,

Thanks for the update. I just tried downloading the Debian package for
1.0.0, but it looks like the checksum on the website is incorrect. I'm
getting 30e425cd33afe3a1a15b46669ba8d631. Could you please confirm that
the package and checksum are ok?

Thanks

Daniel

> Hello All,
>
> Our team is proud and delighted to announce SubGit 1.0.0 release!
> New version is available for download at SubGit web site at
> http://subgit.com/
>
> SubGit is a server-side tool for a smooth, stress-free Svn to Git
> migration. SubGit lets one to set up a bidirectional Subversion to Git
> replication (writable mirror) and thus it allows users to choose
> freely between Subversion and Git version control systems.
>

> SubGit is a closed source Java application, which is free for use in
> Open Source and Academic projects, as well as in any repository with
> up to 10 committers. Besides, there are no limitations on the time you
> may evaluate SubGit in commercial or closed source projects.
>

> A few useful links:
>
> SubGit Web Site: http://subgit.com/
> SubGit Book: http://subgit.com/book/ - nice illustrated guide that
> would help you to install, configure and use SubGit
> SubGit Issues Tracker: http://issues.tmatesoft.com/issues/SGT
>
> With best regards,
> Alexander Kitaev,
> TMate Software,
> http://subgit.com/ - Safe Svn to Git Migration!
> http://svnkit.com/ - Java [Sub]Versioning Library!
> http://hg4j.com/ - Java Mercurial Library!
> http://sqljet.com/ - Java SQLite Library!
>

[Nico Kadel-Garcia]

On Thu, Sep 20, 2012 at 2:31 AM, Andreas Krey <a.k...@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.)

[Stefan Sperling]

On Thu, Sep 20, 2012 at 12:13:45AM -0400, Nico Kadel-Garcia wrote:
> On Wed, Sep 19, 2012 at 3:34 PM, Alexander Kitaev <kit...@tmatesoft.com> wrote:

> > Hello All,
> >
> > Our team is proud and delighted to announce SubGit 1.0.0 release!
> > New version is available for download at SubGit web site at http://subgit.com/
> >
> > SubGit is a server-side tool for a smooth, stress-free Svn to Git
> > migration. SubGit lets one to set up a bidirectional Subversion to Git
> > replication (writable mirror) and thus it allows users to choose
> > freely between Subversion and Git version control systems.
>

> Except, of course when it doesn't. The use of OS specific EOL, which
> git does not support, and subversion keywords like $Id$ and $Author$,
> which git does not support, would seem to me to be an adventure
> begging to happen.

Of course there are problems with trying to do this.

But if you're always afraid of running into pitfalls you'll never
get anything done. I know you are particularly keen on pointing
out pitfalls because you're somebody who often ends up having to
work around them professionally, and I sense some love-hate
relationship going on here :)

We had some very interesting discussions with the Tmate folks
when they first announced SubGit at Subversion Day last year:
http://www.elegosoft.com/en/company/news/news-in-detail.html?tx_ttnews[pointer]=1&tx_ttnews[tt_news]=114&tx_ttnews[backPid]=195&cHash=f876117be36ef5742b4977d7be07b5da
The announcement sparked some interest in German media:
http://www.heise.de/developer/meldung/Transparenter-Abgleich-zwischen-Subversion-und-Git-1246894.html

My own conviction is that their entire endeavor of rewriting
Subversion and related components in Java is outright crazy.
But I'm not a Java developer, so maybe I just don't get it.
And the quality that Tmate produces is astounding, and the
persistence they show with keeping up with Subversion's
feature set in SVNKit is highly commendable.

Generally, the problem they're tackling with SubGit is a giant
compatibility mapping problem between two very different data
structures. It is quite interesting to see how much of that
problem space they can actually solve, and also how long it has
taken them to solve it! One of the developers at Tmate even
made this problem part of his thesis.

So please, before you dismiss these efforts by pointing out
the first minor potential compatibility problem that comes to mind,
pay them some respect for their efforts -- they've certainly
done their homework around keyword expansion, and lots more.

[Stefan Sperling]

On Thu, Sep 20, 2012 at 06:36:02AM -0400, Nico Kadel-Garcia wrote:
> 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.)

That's not embarrassing. That's using the right tool for the job.

[Andreas Krey]

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.

[Stefan Sperling]

On Thu, Sep 20, 2012 at 01:35:26PM +0200, Andreas Krey wrote:
> and the availablility of anything that can serve git and svn
> clients will basically make any more svn updates unneeded.

To be frank, that attitude is just as short-sighted and destructive
to the open source community as is Lennart's crusade in Linux-land
to force everyone on the planet onto his systemd via redhat's giant
hand of influence. (They've been trying to tie projects like GNOME onto
systemd as a hard dependency -- systemd will only ever run on Linux
which means this would limit people's choices.)

There are different projects that fulfill different needs, and we
should strive to keep them alive for as long as they serve a useful
purpose to their users. Users should freely be able choose between
tools and benefit from improvements made to each tool.

In the grand scheme of things, the development of git is entirely
orthogonal to the development of Subversion. They're different tools
made for different requirements.

[Ben Reser]

On Thu, Sep 20, 2012 at 4:35 AM, Andreas Krey <a.k...@gmx.de> wrote:
> On Thu, 20 Sep 2012 06:36:02 +0000, Nico Kadel-Garcia wrote:
>> 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.)

It's worth pointing out that this problem isn't that big of a problem
for them. If they implement one version of our wireline protocol then
they are going to interoperate with us until we bump the major. Yes
they may be missing some features until they catch up, but they will
interoperate.

[Nico Kadel-Garcia]

Except that it can't be merely wire protocol. They're remapping the
commit, copy, delete, move,branch, tag, and merge operations of one
source control into the other. That's..... not directly comparable,
especially the tag operation, which is really designed to be much more
locked down than Subversion has by default. In theory, I suppose you
could lock it down to emulate the git "thou shalt not touch me" model.

And unfortunately, there are Subversion usage models that simply don't
map well to the standard trunk/branches/tags layout, such as matching
simultaneous tags for source code and/or binaries of multiple parallel
projects in the same repository.

[Ben Reser]

On Thu, Sep 20, 2012 at 8:31 PM, Nico Kadel-Garcia <nka...@gmail.com> wrote:
> Except that it can't be merely wire protocol. They're remapping the
> commit, copy, delete, move,branch, tag, and merge operations of one
> source control into the other. That's..... not directly comparable,
> especially the tag operation, which is really designed to be much more
> locked down than Subversion has by default. In theory, I suppose you
> could lock it down to emulate the git "thou shalt not touch me" model.
>
> And unfortunately, there are Subversion usage models that simply don't
> map well to the standard trunk/branches/tags layout, such as matching
> simultaneous tags for source code and/or binaries of multiple parallel
> projects in the same repository.

Just because there are use cases that you can see that it doesn't
cover doesn't mean it's not useful for someone. In this particular
case it's like complaining that a bicycle isn't very useful in getting
across the Atlantic and using that as an argument that nobody should
make bicycles.

I'm not going to bother responding to this thread further. It really
has no place on the d...@subversion.apache.org or
us...@subversion.apache.org list as Brane has wisely pointed out.