You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Alexander Kitaev <ki...@tmatesoft.com> on 2012/09/19 21:34:19 UTC
[ANN] SubGit 1.0.0 is released
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!
Re: [ANN] SubGit 1.0.0 is released
Posted by Andreas Krey <a....@gmx.de>.
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
Re: [ANN] SubGit 1.0.0 is released
Posted by Andreas Krey <a....@gmx.de>.
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
Re: [ANN] SubGit 1.0.0 is released
Posted by Stefan Sperling <st...@elego.de>.
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 <ki...@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.
Re: [ANN] SubGit 1.0.0 is released
Posted by Stefan Sperling <st...@elego.de>.
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 <ki...@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.
Re: [ANN] SubGit 1.0.0 is released
Posted by Branko Čibej <br...@wandisco.com>.
On 20.09.2012 08:31, Andreas Krey 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
> 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.
I'm sure there are any number of forums out there that specialize in
Subversion-vs.-Git bashing. This is not one of them. Take this
"discussion" somewhere else, thanks.
-- Brane
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: [ANN] SubGit 1.0.0 is released
Posted by Stefan Sperling <st...@elego.de>.
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.
Re: [ANN] SubGit 1.0.0 is released
Posted by Ben Reser <be...@reser.org>.
On Thu, Sep 20, 2012 at 8:31 PM, Nico Kadel-Garcia <nk...@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 dev@subversion.apache.org or
users@subversion.apache.org list as Brane has wisely pointed out.
Re: [ANN] SubGit 1.0.0 is released
Posted by Ben Reser <be...@reser.org>.
On Thu, Sep 20, 2012 at 8:31 PM, Nico Kadel-Garcia <nk...@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 dev@subversion.apache.org or
users@subversion.apache.org list as Brane has wisely pointed out.
Re: [ANN] SubGit 1.0.0 is released
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Thu, Sep 20, 2012 at 12:44 PM, Ben Reser <be...@reser.org> wrote:
> On Thu, Sep 20, 2012 at 4:35 AM, Andreas Krey <a....@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.
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.
Re: [ANN] SubGit 1.0.0 is released
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Thu, Sep 20, 2012 at 12:44 PM, Ben Reser <be...@reser.org> wrote:
> On Thu, Sep 20, 2012 at 4:35 AM, Andreas Krey <a....@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.
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.
Re: [ANN] SubGit 1.0.0 is released
Posted by Ben Reser <be...@reser.org>.
On Thu, Sep 20, 2012 at 4:35 AM, Andreas Krey <a....@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.
Re: [ANN] SubGit 1.0.0 is released
Posted by Andreas Krey <a....@gmx.de>.
On Thu, 20 Sep 2012 14:18:11 +0000, Thorsten Schöning wrote:
...
> I maybe misunderstand your argumentation but the only thing I read
> over and over again is: Use git, it's superior.
Well, it is. :-) [As I said, in my domain but I think not just in my
opinion.] But I was discussing why that meant some of the critics against
subgit and similar tools are simply not applicable.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: [ANN] SubGit 1.0.0 is released
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Andreas Krey,
am Donnerstag, 20. September 2012 um 13:35 schrieben Sie:
> 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.
I maybe misunderstand your argumentation but the only thing I read
over and over again is: Use git, it's superior. Not that I'm
surprised, it's the same argument I read a dozens of times in each and
every discussion about git vs. Subversion, but you could save a lot of
time if you wouldn't package this small sentence in this much text.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon.............030-2 1001-310
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: [ANN] SubGit 1.0.0 is released
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Sep 20, 2012 at 09:58:33AM -0400, Andy Singleton wrote:
> I frequently see people choosing between git and subversion, and/or
> migrating, usually to git. By this measure, the use cases are not
> orthogonal. I argue that people choose subversion for good reasons.
> It's simpler (and so works for more contributors, including
> designers) and it handles big files and big repositories - much
> bigger than git. However, code files are surprisingly small, so for
> developers working with code, who want to use modern workflows that
> require merging into integration and production versions, the
> problems with svn merge are often a deciding factor.
Yes, because git is currently geared towards these requirements
in a much better way than Subversion is. So please, use git for
this and consider using Subversion for other projects which it is
more suitable for. If you really must refactor your project once
a week and move things around, Subversion currently won't automate
much of this process for you.
However, for software projects where the project's directory
structure remains mostly static, Subversion's merge functionality
is perfectly fine. There are many examples of big projects like
this that use Subversion (Subversion itself, FreeBSD, most projects
at the ASF, ...).
> Julian's work is a BIG improvement in usability. However, it
Agreed!
> doesn't make many adjustments to the underlying algorithms. I know
> that Stefan is working on fixing problems that happen when we move
> files. However, I was warned that this will be a slow process.
It is slow because we're trying to retrofit requirements into the system
which it hasn't been designed for, while keeping everything else working.
> It's worth noting that Linus solved most git merge
> problems in about six months, with approximate heuristics, where the
> Subversion team has worked on the same problems for 6 years with
> less progress.
That's a misleading statement.
The problem has been known for ages, and the project has been working
towards fixing it for a long time now. But we haven't been working on
this single problem for 6 years. It's not like all we ever did for
6 years during Subversion development is trying to fix problem
with moves. There are many other areas of development.
You also have to keep the design issues in mind. Linus was working
with a design that made the problem easy to deal with. We're working
with a design that makes this problem hard to deal with. But we're
stuck with this design, and the design solves a whole host of other
problems that git doesn't solve (some of which you've already pointed
out yourself).
> Is precision worth the effort?
I don't think it's a question of precision, in the sense that that
using heuristics would magically buy us some development time.
It looks like we'll simply be asking the user what to do about
cases where git applies it's non-100% heuristics. That gives us
100% precision if users provide the correct input :)
> I agree that it would be useful to have a kickstarter project and
> some substantial bounty money available for the next set of fixes to
> either merge or move. I'm in.
More development resources would definitely be welcome.
> I would like to be able to make a workflow recommendation that makes
> subversion relevant for a fast growing class of development
> projects.
If this recommendation doesn't lead to the desired level of
productivity then it is the wrong recommendation to make.
Subversion will eventually be able to handle this better, but it
will take time to get here. Luckily, there are other tools that
fill these gaps in the meantime.
Re: [ANN] SubGit 1.0.0 is released
Posted by Branko Čibej <br...@wandisco.com>.
On 20.09.2012 15:58, Andy Singleton wrote:
> On 9/20/2012 8:27 AM, Stefan Sperling wrote:
>> 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.
>
> I would like to get a specific list of cases where this is true. It
> is true that if you have a large, old, mixed revision repository that
> is on Subversion now, you will want to keep your Subversion.
For the sake of precision, I'll just point out that there's no such
thing as a "mixed-revision repository" in Subversion. There are
mixed-revision working copies, but as far as I can see, neither subgit
nor git itself make any attempt to deal with that model.
-- Brane
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: [ANN] SubGit 1.0.0 is released
Posted by Andy Singleton <an...@assembla.com>.
On 9/20/2012 8:27 AM, Stefan Sperling wrote:
> 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.
I would like to get a specific list of cases where this is true. It is
true that if you have a large, old, mixed revision repository that is on
Subversion now, you will want to keep your Subversion. What are the
other cases where you will prefer Subversion? Can we brainstorm that?
I'd like to have a list of these use cases so that I can make good
recommendations.
I frequently see people choosing between git and subversion, and/or
migrating, usually to git. By this measure, the use cases are not
orthogonal. I argue that people choose subversion for good reasons.
It's simpler (and so works for more contributors, including designers)
and it handles big files and big repositories - much bigger than git.
However, code files are surprisingly small, so for developers working
with code, who want to use modern workflows that require merging into
integration and production versions, the problems with svn merge are
often a deciding factor.
I am struggling to see the specific use case for Subgit, where
developers use the git view and the svn view at the same time. You are
going to get better results from your development workflow if all of
your developers use one recommended repository format. There is a
argument for "cloning" subversion subdirectories (bits of a bigger
repository) as git repositories for individuals. Can we do that with
Subgit? My friends at Accurev and Perforce have both added git clone of
subdirectories to their products. The argument is that developers like
to use git locally and offline, but repository owners like to have their
assets in one repository that is too big for git. This approach fits
the mixed-revision-subtree case that is supported in Subversion, since
it clones and revises subtrees.
At Assembla, we are interested in workflows to support continuous
delivery, like this:
http://blog.assembla.com/assemblablog/tabid/12618/bid/87901/Continuous-Delivery-and-Scalable-Agile-Find-Out-the-Secret.aspx
. Most people (as we did) adopt git when they move to continuous
delivery. This places limits on their contributor set (because git is
complicated) and repository size, and it does mean that they have to
migrate from their subversion repositories.
So, we've been building a code review and merge system that will work
with Subversion 1.8 . There is some question about whether we have made
enough progress in Subversion merge to make it competitive for
development teams that are considering workflows that require merging.
One solution is to limit the cases where we apply merge, so that we
increase the success rate. For example, in the Assembla system, we will
only branch and merge at the top level. We have been making temporary
branches for each task, merging them, and removing them. This
short-lived approach avoids some problems. Maybe with symmetric merge,
we will be able to succeed with a longer branch lifetime that is closer
to the way that most people use svn branches now.
Julian's work is a BIG improvement in usability. However, it doesn't
make many adjustments to the underlying algorithms. I know that Stefan
is working on fixing problems that happen when we move files. However,
I was warned that this will be a slow process.
I started some proposals for more fundamental changes, but these
proposals were rejected. To review:
1) Eliminate mixed revision subtrees. This was rejected because,
apparently, there are a lot of big repositories out there with mixed
revision directories, and this is a core use case. Maybe it is THE core
use case. That makes things complicated.
2) Track actual merge history, rather than the integer "mergeinfo". It
seems silly not to have a full history, as people working on merge would
find it very useful. However, this would probably require change (1),
so that each branch has one merge history.
3) Fix the problems that occur after moves. Git uses a heuristic to
find moved files by pattern matching. The Subversion team has committed
to fixing move problems, realizing that a large percentage of merge and
update complaints come from moves. However, they have decided to take a
more precise and difficult path than the simple pattern match. It's
worth noting that Linus solved most git merge problems in about six
months, with approximate heuristics, where the Subversion team has
worked on the same problems for 6 years with less progress. Is
precision worth the effort?
I agree that it would be useful to have a kickstarter project and some
substantial bounty money available for the next set of fixes to either
merge or move. I'm in.
I would like to be able to make a workflow recommendation that makes
subversion relevant for a fast growing class of development projects.
--
Andy Singleton
Founder/CEO, Assembla Online: http://www.assembla.com
Phone: 781-328-2241
Skype: andysingleton
Re: UNS: Re: [ANN] SubGit 1.0.0 is released
Posted by Branko Čibej <br...@wandisco.com>.
On 20.09.2012 14:44, Andreas Krey wrote:
> On Thu, 20 Sep 2012 14:27:20 +0000, Stefan Sperling wrote:
>> 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
> Oh, I didn't mean that svn1.8 would be unnecessary; I meant that a server
> working with git and svn clients would generally be a migrational tool and
> wouldn't need to follow svn. I recognise that there are use cases for svn,
> I just don't have any around here.
I expect you mean migrational in the sense of users migrating from git
to svn, right? :)
-- Brane
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: UNS: Re: [ANN] SubGit 1.0.0 is released
Posted by Andreas Krey <a....@gmx.de>.
On Thu, 20 Sep 2012 14:27:20 +0000, Stefan Sperling wrote:
> 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
Oh, I didn't mean that svn1.8 would be unnecessary; I meant that a server
working with git and svn clients would generally be a migrational tool and
wouldn't need to follow svn. I recognise that there are use cases for svn,
I just don't have any around here.
...
> 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.
Systemd has the same problem as svn/git. They are not per-user decisions
but need to be made on a more global scale.
> 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.
...with the problem that a lot of svn uses were decided back when git
wasn't known/available but git would be the proper tool now, were it not
for migration effort. subgit would lower that barrier.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: UNS: Re: [ANN] SubGit 1.0.0 is released
Posted by Andreas Krey <a....@gmx.de>.
On Thu, 20 Sep 2012 14:27:20 +0000, Stefan Sperling wrote:
> 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
Oh, I didn't mean that svn1.8 would be unnecessary; I meant that a server
working with git and svn clients would generally be a migrational tool and
wouldn't need to follow svn. I recognise that there are use cases for svn,
I just don't have any around here.
...
> 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.
Systemd has the same problem as svn/git. They are not per-user decisions
but need to be made on a more global scale.
> 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.
...with the problem that a lot of svn uses were decided back when git
wasn't known/available but git would be the proper tool now, were it not
for migration effort. subgit would lower that barrier.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: [ANN] SubGit 1.0.0 is released
Posted by Stefan Sperling <st...@elego.de>.
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.
Re: [ANN] SubGit 1.0.0 is released
Posted by Stefan Sperling <st...@elego.de>.
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.
Re: [ANN] SubGit 1.0.0 is released
Posted by Ben Reser <be...@reser.org>.
On Thu, Sep 20, 2012 at 4:35 AM, Andreas Krey <a....@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.
Re: [ANN] SubGit 1.0.0 is released
Posted by Andreas Krey <a....@gmx.de>.
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
Re: [ANN] SubGit 1.0.0 is released
Posted by Stefan Sperling <st...@elego.de>.
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.
Re: [ANN] SubGit 1.0.0 is released
Posted by Andreas Krey <a....@gmx.de>.
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
Re: [ANN] SubGit 1.0.0 is released
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Thu, Sep 20, 2012 at 2:31 AM, Andreas Krey <a....@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
Re: [ANN] SubGit 1.0.0 is released
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Thu, Sep 20, 2012 at 2:31 AM, Andreas Krey <a....@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
Re: [ANN] SubGit 1.0.0 is released
Posted by Andreas Krey <a....@gmx.de>.
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.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: [ANN] SubGit 1.0.0 is released
Posted by Andreas Krey <a....@gmx.de>.
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.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: [ANN] SubGit 1.0.0 is released
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Wed, Sep 19, 2012 at 3:34 PM, Alexander Kitaev <ki...@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.
Re: [ANN] SubGit 1.0.0 is released
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Wed, Sep 19, 2012 at 3:34 PM, Alexander Kitaev <ki...@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.