Re: If RCS can stand it, why can’t your system?

[Greg Stein <gs...@gmail.com>]

We have an import/export format that has existed since svn 1.0, and
that is our dumpfile format. I do not think we are "required" or need
to be "shamed" into supporting additional formats.

And for what it's worth, a *git* GSoC student wrote a remote dumpfile
generator to feed into git's fast-import. We gave the guy commit
access to *our* trunk and let him build the tool.

Also: we have extended our diff generation to support git's diff markers.

In short, there is NO WAY anybody can say we have something against
git. If somebody came along with code to deal with git's streams, then
we'd consider it, and the utility it may provide over our own dumpfile
format.

So I'm not quite sure what your post and tool is supposed to be saying
to our community. I don't get it.

-g

On Thu, Nov 25, 2010 at 02:25, Eric Raymond <es...@snark.thyrsus.com> wrote:
> I’ve written software for a lot of different reasons besides pure
> utility in the past. Sometimes I’ve been making an aesthetic
> statement, sometimes I’ve hacked to perpetuate a tribal in-joke, and
> at least once I have written a substantial piece of code exactly
> because the domain experts solemnly swore that job was impossible to
> automate (wrong, bwahahaha).
>
> Here’s a new one. Today I released a program that is ugly and only
> marginally useful, but specifically designed to shame other hackers
> into doing the right thing.
>
> The rest at <http://esr.ibiblio.org/?p=2762>.
> --
>                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>
> No kingdom can be secured otherwise than by arming the people.  The possession
> of arms is the distinction between a freeman and a slave.
>        -- "Political Disquisitions", a British republican tract of 1774-1775
>

Re: If RCS can stand it, why can’t your system?

[Ramkumar Ramachandra <ar...@gmail.com>]

Hi,

Eric Raymond writes:
> Ramkumar Ramachandra <ar...@gmail.com>:
> > `svnrdump (dump|load)` behaves almost exactly like `svnadmin
> > (dump|load)` over the network.
> 
> What do you mean 'over the network'? Can I get a exported stream on stdout
> from the dump mode?  Can I feed a stream on stdin to the load mode?

Yep, it does *exactly* that :)

$ svnrdump help dump
dump: usage: svnrdump dump URL [-r LOWER[:UPPER]]

Dump revisions LOWER to UPPER of repository at remote URL to stdout in a 'dumpfile' portable format.
If only LOWER is given, dump that one revision.

$ svnrdump help load
load: usage: svnrdump load URL

Load a 'dumpfile' given on stdin to a repository at remote URL.

> > http://git.kernel.org/?p=git/git.git;a=blob;f=contrib/svn-fe/svn-fe.txt
> 
> Looks like "svnadmin dump --incremental REPO | svn-fe" the export command
> reposurgeon needs, but I'm not clear what the corresponding import 
> command would be.

Yes, that is correct. You might consider using svnrdump for local
repositories as well though- just use 'file://<path>' in place of
'<path>'; it's faster than svnadmin in some bechmarks. You can
"import" once we finish building the git fast-import stream ->
dumpfile converter :)

-- Ram

Re: If RCS can stand it, why can’t your system?

[Ramkumar Ramachandra <ar...@gmail.com>]

Hi Eric,

Eric Raymond writes:
> Ramkumar Ramachandra <ar...@gmail.com>:
> > Yep, that's completely true. I am that GSoC student, and
> > subversion/svnrdump is complete. The Subversion community was
> > supportive of it. And yes, I wrote both "dump" and "load"
> > functionality. So there is some factual inaccuracy in your statement:
> > "Subversion is typical in that it has a proof-of-concept third-party
> > exporter that loses some metadata, and no importer"
> 
> Thanks for the information.  Where can I find documentation on this
> capability?  I'm particularly interested in how it handles the two
> issues I mentioned - mapping between Subversion's server-loxcal commit
> identities and import=-stream's full addresses, and mapping between
> Subversion merge-tracking info and the input-stream's commit-ancestry
> fields.

`svnrdump (dump|load)` behaves almost exactly like `svnadmin
(dump|load)` over the network. The conversion to git fast-import is
merged into git.git: the infrastructure is in ^/vcs-svn and a small
end-user tool is available in ^/contrib/svn-fe -- usage information is
in svn-fe.txt:
http://git.kernel.org/?p=git/git.git;a=blob;f=contrib/svn-fe/svn-fe.txt

It currently doesn't handle any of the issues you mentioned- we
haven't built the mapper yet, and it's just a dumb converter at the
moment. We are currently working on some plumbing to support
incremental imports, and build a remote helper. After that, we will
work on the mapper and the git fast-import -> dumpfile v3 converter to
feed `svnrdump load`. Also, there has been a lot of discussion about
the mapper on the mailing list, and here's one particularly huge
thread:
http://thread.gmane.org/gmane.comp.version-control.git/158940/focus=159054

Hope that helps :)

> > Since Subversion already has so much infrastructure to deal with
> > deltified dumpfile, I'd vote to keep that as the native import/export
> > format.
> 
> That decision is orthogonal to what I'm interested in, and I have no
> position on it.

Ok.

-- Ram

Re: If RCS can stand it, why can’t your system?

[Ramkumar Ramachandra <ar...@gmail.com>]

Hi Eric,

Greg Stein writes:
> We have an import/export format that has existed since svn 1.0, and
> that is our dumpfile format. I do not think we are "required" or need
> to be "shamed" into supporting additional formats.
> 
> And for what it's worth, a *git* GSoC student wrote a remote dumpfile
> generator to feed into git's fast-import. We gave the guy commit
> access to *our* trunk and let him build the tool.

Yep, that's completely true. I am that GSoC student, and
subversion/svnrdump is complete. The Subversion community was
supportive of it. And yes, I wrote both "dump" and "load"
functionality. So there is some factual inaccuracy in your statement:
"Subversion is typical in that it has a proof-of-concept third-party
exporter that loses some metadata, and no importer"

We have also finished building a converter from dumpfilev3 -> git
fast-import stream, and are currently working on building the
reverse. That way, there should be no bias and people should be able
to move into Subversion as easily as they can move out of it.

At most, you could criticize the fact that we weren't able to build it
earlier/ faster. Yes, it was a very non-trivial task (atleast for me).

> Also: we have extended our diff generation to support git's diff markers.

Indeed. Daniel did this as part of another GSoC project. `svn diff
--git` works perfectly now.

> In short, there is NO WAY anybody can say we have something against
> git. If somebody came along with code to deal with git's streams, then
> we'd consider it, and the utility it may provide over our own dumpfile
> format.

Since Subversion already has so much infrastructure to deal with
deltified dumpfile, I'd vote to keep that as the native import/export
format.

-- Ram

RE: If RCS can stand it, why can't your system?

["Bolstridge, Andrew" <an...@intergraph.com>]

*I thought* he was saying it's not good for a community/tool when people develop exporters that take dumps from their system and use it to write importers into competing tools (eg GIT) without providing the reverse.

What he thinks we should be doing is writing *importers* for our tool, to take git dumps and import them to SVN. The problem is that it is now easy to migrate from SVN to git, but it's not so easy to migrate from git to SVN.

I guess this state of play is quite normal - new stuff always has people willing to write tools to support it. I wrote a VSS to SVN importer, because I needed one, but no-one really needs a git to SVN importer as git is the new kid. Maybe one day they'll see the need to migrate from git, and someone will then write the tool to do that.

Perhaps Mr Raymond will put his money where his mouth is and write this git->svn tool if reposurgeon makes it so easy.

<stands back and waits for Eric to say "I'll bloody well show him", and write it> :)



> -----Original Message-----
> From: Greg Stein [mailto:gstein@gmail.com]
> Sent: 27 November 2010 09:49
> To: Eric Raymond
> Cc: dev@subversion.apache.org
> Subject: Re: If RCS can stand it, why can't your system?
> 
> We have an import/export format that has existed since svn 1.0, and that is
> our dumpfile format. I do not think we are "required" or need to be
> "shamed" into supporting additional formats.
> 
> And for what it's worth, a *git* GSoC student wrote a remote dumpfile
> generator to feed into git's fast-import. We gave the guy commit access to
> *our* trunk and let him build the tool.
> 
> Also: we have extended our diff generation to support git's diff markers.
> 
> In short, there is NO WAY anybody can say we have something against git. If
> somebody came along with code to deal with git's streams, then we'd
> consider it, and the utility it may provide over our own dumpfile format.
> 
> So I'm not quite sure what your post and tool is supposed to be saying to our
> community. I don't get it.
> 
> -g
> 
> On Thu, Nov 25, 2010 at 02:25, Eric Raymond <es...@snark.thyrsus.com>
> wrote:
> > I've written software for a lot of different reasons besides pure
> > utility in the past. Sometimes I've been making an aesthetic
> > statement, sometimes I've hacked to perpetuate a tribal in-joke, and
> > at least once I have written a substantial piece of code exactly
> > because the domain experts solemnly swore that job was impossible to
> > automate (wrong, bwahahaha).
> >
> > Here's a new one. Today I released a program that is ugly and only
> > marginally useful, but specifically designed to shame other hackers
> > into doing the right thing.
> >
> > The rest at <http://esr.ibiblio.org/?p=2762>.
> > --
> >                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
> >
> > No kingdom can be secured otherwise than by arming the people.  The
> > possession of arms is the distinction between a freeman and a slave.
> >        -- "Political Disquisitions", a British republican tract of
> > 1774-1775
> >