From: Ramkumar Ramachandra <artagnon@gmail.com>
To: Git Mailing List <git@vger.kernel.org>
Cc: Sverre Rabbelier <srabbelier@gmail.com>,
Jonathan Nieder <jrnieder@gmail.com>,
David Michael Barr <david.barr@cordelta.com>,
Daniel Shahaf <d.s@daniel.shahaf.name>,
Sam Vilain <sam@vilain.net>, Eric Wong <normalperson@yhbt.net>,
Junio C Hamano <gitster@pobox.com>,
"Shawn O. Pearce" <spearce@spearce.org>
Subject: [GSoC update] git-remote-svn: Week 9
Date: Thu, 1 Jul 2010 15:13:10 +0200 [thread overview]
Message-ID: <20100701131310.GA28607@debian> (raw)
Hi,
In terms of code, this week was unproductive. However, there was one
very long and productive discussion about the design of svn-fe. We can
now prove that the design of svn-fe is most efficient, and that any
other dumpfile importer will do worse than svn-fe. I'll put this proof
down in another email, and use this one for just a status update. We
have also determined that some some extensions to git-fast-import will
significantly reduce the complexity of svn-fe. Here are the current
list of tasks along with their status:
1. The svnclient_ra. I have stopped working on a stopgap
implementation of svnclient_ra that dumps full text/ props; to do
this, it needs to interrupt a replay and open a new connection- it
seems that this is quite non-trivial to get right. I've decided to
complete the delta dump generator instead. Unfortunately, this
means that I won't have a complete chain to show a remote helper by
mid-term evaluations: just individual components.
2. Ternary treap fork. This only changes the underlying data
structure- nothing else should change. David is close to completing
this.
3. Make svn-fe support deltified dumps. This can only be done after we
have a Git object store backing. Deferred for the moment.
4. git-fast-import only supports filecopy for trees from the parent
commit; make it support copies from all commits. Jonathan has
already sent an RFC patch on the list for this.
5. Zero-tree fork. svn-fe currently maintains trees for all revisions;
Jonathan suggested that it can lazily fetch tree objects from the
Git store backing. This change will significantly reduce the
complexity of svn-fe.
6. git-fast-import needs to be extended to print-marks. Sverre
suggested this, and Jonathan has sent an RFC patch on the
list. This is required for the Git object store to communicate back
commit hashes to the caller (svn-fe in this case).
In other news, we managed to get colabti.org to log the channel where
we have most of our discussions: #git-devel on Freenode IRC. This
information is probably helpful for other GSoC students and developers
who are looking to collaborate on projects.
-- Ram
next reply other threads:[~2010-07-01 13:37 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-01 13:13 Ramkumar Ramachandra [this message]
2010-07-02 1:40 ` [GSoC update] git-remote-svn: Week 9 Bo Yang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100701131310.GA28607@debian \
--to=artagnon@gmail.com \
--cc=d.s@daniel.shahaf.name \
--cc=david.barr@cordelta.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
--cc=normalperson@yhbt.net \
--cc=sam@vilain.net \
--cc=spearce@spearce.org \
--cc=srabbelier@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.