Hi,
I think it falls very close to the native-git-svn Google SoC
project[1], and if you are able to share what you have I'm sure
Ramkumar (I hope you don't mind me CC'ing you, and that I spelled your
name right) would appreciate having a look.
Yes. Thank you for CC'ing me, Erik.
Is it worthwhile to start a new project - or would it be better to grok the internals of existing projects and try to make them scale?
Honestly, I've just started looking into this issue, so I'll wait for
someone else to comment on this. As far as interest is concerned, yes-
a lot of people seem to be pretty excited about my GSoC project
proposal [1]. My proposal has more to do with getting native support
working, than building a fantastic SVN importer. I certainly have
neither the time or experience to build an SVN importer that's any
better than git-svn.perl in the summer term, and I'm clear that I
don't intend to do this. However, if my proposal gets accepted, I
could work with you to get it integrated into the remote helper that
I'll be building. Depending on the complexity of your project, this
might only be possible at the end of my GSoC term.
[1] http://thread.gmane.org/gmane.comp.version-control.git/142623
-- Ram
Hi,
quoted
I think it falls very close to the native-git-svn Google SoC
project[1], and if you are able to share what you have I'm sure
Ramkumar (I hope you don't mind me CC'ing you, and that I spelled your
name right) would appreciate having a look.
Yes. Thank you for CC'ing me, Erik.
quoted
Is it worthwhile to start a new project - or would it be better to grok the internals of existing projects and try to make them scale?
However, if my proposal gets accepted, I
could work with you to get it integrated into the remote helper that
I'll be building. Depending on the complexity of your project, this
might only be possible at the end of my GSoC term.
From Ramkumar's proposal[1]:
The distinct components I plan to write are:
2. An exporter for SVN repositories, which will extract all the
relevant revision history and metadata to import into Git.
3. A remote helper for Git that takes the data from this SVN exporter,
and uses git-fast-import to create corresponding commits in Git.
The scope of my project roughly corresponds to these two components.
With regard to licensing issues, I opted to work only with import/export streams so that no linking is required.
In the context of GSoC, I am studying my final year of a Bachelor of Science (Computer Science x 2) at Australian National University, Canberra.
As for FOSS contributions, the last time I released something was when I helped port the iBurst wireless broadband driver (USB interface) [2] a few years ago; the demands of life vs. one's passion.
Hi,
quoted
I think it falls very close to the native-git-svn Google SoC
project[1], and if you are able to share what you have I'm sure
Ramkumar (I hope you don't mind me CC'ing you, and that I spelled your
name right) would appreciate having a look.
Yes. Thank you for CC'ing me, Erik.
quoted
Is it worthwhile to start a new project - or would it be better to grok the internals of existing projects and try to make them scale?
... if my proposal gets accepted, I
could work with you to get it integrated into the remote helper that
I'll be building. Depending on the complexity of your project, this
might only be possible at the end of my GSoC term.
-- Ram
I've started looking at the first piece of the pipeline, reading from a
remote subversion URL. I stumbled upon rsvndump[2], which is
GPLv3+ licensed and promises to produce a Subversion dump from
a remote repository. This could be piped to my utility,
svn-dump-fast-export[3], to produce suitable input for git fast-import.
I believe this would address the first two components of Ram's.
proposal and allow more focus to be given to the interesting ones.
That's presuming that I have a feature-complete release by the time
the GSoC project begins.
My project is currently under a two-clause BSD style license.
This is primarily because the two projects it derives from were
distributed under the same license, rather than any preference.
As I've included a reference to my project, I'll emphasise that it is a
work in progress, with a handful of known bugs.
At present, symlinks are damaged on update and some files
disappear late in the history of my test repository.
I'm planning a rewrite of the parser once symlinks are complete.
[1] http://thread.gmane.org/gmane.comp.version-control.git/142623
[2] http://rsvndump.sourceforge.net/
[3] http://github.com/barrbrain/svn-dump-fast-export/
Hi,
On Tue, Mar 30, 2010 at 7:35 PM, David Michael Barr
[off-list ref] wrote:
I've started looking at the first piece of the pipeline, reading from a
remote subversion URL. I stumbled upon rsvndump[2], which is
GPLv3+ licensed and promises to produce a Subversion dump from
a remote repository. This could be piped to my utility,
svn-dump-fast-export[3], to produce suitable input for git fast-import.
In the latest version of my proposal, I've proposed to write a
mirroring tool which will basically be a stripped down version of
svnsync [1]. For testing, I therefore recommend that you use svnsync
instead of rsvndump because the former is included in the official
source tree. If however, you do a comparison and find that rsvndump is
actually a better alternative, let me know.
I believe this would address the first two components of Ram's.
proposal and allow more focus to be given to the interesting ones.
That's presuming that I have a feature-complete release by the time
the GSoC project begins.
That's fantastic! I suspect you haven't looked at the latest revision
of my proposal. Since Gmane doesn't seem to have indexed it, I just
sent you a mail off the list.
-- Ram