From: "Shawn O. Pearce" <spearce@spearce.org>
To: Julian Phillips <julian@quantumfyre.co.uk>
Cc: Bruno Cesar Ribas <ribas@c3sl.ufpr.br>, git@vger.kernel.org
Subject: Re: Git / Subversion Interoperability
Date: Thu, 22 Mar 2007 21:24:23 -0400 [thread overview]
Message-ID: <20070323012422.GC17773@spearce.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0703230052570.2746@beast.quantumfyre.co.uk>
Julian Phillips <julian@quantumfyre.co.uk> wrote:
> On Thu, 22 Mar 2007, Shawn O. Pearce wrote:
> >Bruno Cesar Ribas <ribas@c3sl.ufpr.br> wrote:
> >>2. write a backend for Subversion
> >
> >In this case we try to reuse the existing SVN server code by
> >creating a library module that plugs into that system
...
> >downside is you have to write code to run within their library and
> >address space, and that conforms to their storage API.
>
> This might run headlong into some of the issues facing the libification
> project - in particular the tendancy of git code to die as a primary error
> handling mechanism. This approach may not viable without access to a
> libified git?
Yes, exactly. The libification won't be ready early enough for
this project. So that does make it more difficult. But this just
points out another reason why libification might be useful. ;-)
> >- Branches. In SVN these are in the repository wide namespace,
> >but in Git they aren't. I imagine we'd want to just enforce the
> >standard layout that the SVN people recommened:
...
> That would probably be good enough for the majority of
> one-project-per-repo Subversion projects at least. Though there is still
> the issue that Subversion will actually let you create a "tag" simply by
> committing whatever you currently have in your working copy (including
> localally modified files ... yeuch).
Heh. People do weird things. ;-)
> >That's all I can think of right now. But I'm sure there are more.
>
> Properties are probably the next biggest headache. Subversion allows you
> to associate arbitrary keyword value pairs with files (which are
> versioned) and with revisions (which are not versioned). You would need
> to find someway to support this in git. Since revision properties are
> disabled by default in Subversion you may be able to simply disallow them
> permanently - but I don't know anything about the Subversion protocol ...
I thought about the properties, but didn't bother to write anything
on that subject as we may just be able to say "look, properties
are not supported in git-svnserver, so don't try to use them".
The git-svnserver is meant to help users migrate to Git, not to offer
up all of SVNs features and warts. A big part of this project may
just be deciding what features we are willing to try to emulate.
--
Shawn.
next prev parent reply other threads:[~2007-03-23 1:24 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-22 22:48 Git / Subversion Interoperability Bruno Cesar Ribas
2007-03-23 0:43 ` Shawn O. Pearce
2007-03-23 1:03 ` Julian Phillips
2007-03-23 1:24 ` Shawn O. Pearce [this message]
2007-03-23 1:36 ` Julian Phillips
2007-03-23 10:34 ` Karl Hasselström
2007-03-23 15:21 ` Bruno Cesar Ribas
2007-03-23 15:48 ` Karl Hasselström
2007-03-23 18:13 ` Julian Phillips
2007-03-23 19:34 ` Bruno Cesar Ribas
2007-03-23 22:05 ` David Lang
2007-03-23 22:11 ` Daniel Barkalow
2007-03-24 6:41 ` Shawn O. Pearce
2007-03-24 18:55 ` Karl Hasselström
2007-03-24 20:13 ` Linus Torvalds
2007-03-24 20:37 ` Junio C Hamano
2007-03-26 3:06 ` Sam Vilain
2007-03-23 21:30 ` Christian Wiese
2007-03-23 22:00 ` Steven Grimm
2007-03-24 6:56 ` Shawn O. Pearce
2007-03-26 3:04 ` Sam Vilain
2007-03-23 14:21 ` Jakub Narebski
2007-03-24 6:45 ` Shawn O. Pearce
2007-03-24 20:38 ` Eric Wong
2007-03-24 20:31 ` Eric Wong
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=20070323012422.GC17773@spearce.org \
--to=spearce@spearce.org \
--cc=git@vger.kernel.org \
--cc=julian@quantumfyre.co.uk \
--cc=ribas@c3sl.ufpr.br \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).