From: Florian Achleitner <florian.achleitner2.6.31@gmail•com>
To: Jonathan Nieder <jrnieder@gmail•com>
Cc: Git Mailing List <git@vger•kernel.org>,
Ramkumar Ramachandra <artagnon@gmail•com>,
David Barr <davidbarr@google•com>,
Andrew Sayers <andrew-git@pileofstuff•org>,
Sverre Rabbelier <srabbelier@gmail•com>,
Dmitry Ivankov <divanorama@gmail•com>,
Tomas Carnecky <tom@dbservice•com>
Subject: Re: GSOC Proposal draft: git-remote-svn
Date: Sat, 14 Apr 2012 22:15:53 +0200 [thread overview]
Message-ID: <2407098.F5IbgLFxk2@flomedio> (raw)
In-Reply-To: <20120413191908.GC2387@burratino>
Hi!
Thanks for your help.
I updated the wiki page.
On Friday 13 April 2012 14:19:08 Jonathan Nieder wrote:
> > Really -c? My installed git doesn't have that switch. Should it pass
> > arguments to the remote-helper?
>
> What git version do you use? "man git clone" tells me that -c is an
> abbreviation for --config and "grep -e --config Documentation/RelNotes/*"
> tells me it was introduced in v1.7.7.
Sorry, that was clumsy, I should use build and search the docs of the current
version, not the one my distro ships!
> >
> > What does it mean, "import the entire project tree"? Importing other
> > directories than "trunk"?
>
> Yes. For an import that is going to be dumping the subdirectories of
> tags/ and branches/ anyway, it seems sensible to ask svnrdump to dump
> the entire {trunk,tags,branches} hierarchy and sort it out on the git
> side. The question is then: for each rev, in addition to making
> commits for each branch that changed, should we keep a commit
> representing the state of the combined whole-project tree for internal
> use? A person trying to check out this commit would get to see the
> enormous
>
> trunk/
> tags/
> branches/
>
> directories. My rough answer was "yes, it's convenient to keep that
> information around, especially given that with git's repository model
> it doesn't waste a lot of space and makes debugging easier".
Sounds reasonable.
>
> > About the mapping of git commits to svn refs .. I've seen the thread
> > about the marks-to-notes converter.
> > But can somebody please explain what it's for? There is this mark file
> > mentioned in the git-fast-import help page ..
>
> There are two operations that need to be very fast:
>
> 1. Given a Subversion revision number, what is the corresponding git
> commit? svn-fe uses this to get the preimage data when executing
> an "svn copy" operation that refers to an old rev. For example:
>
> svn copy some/path@a-long-time-ago another/path
>
> Code tracking branches would use this same map to find the
> appropriate parent commit for a new branch. For example:
>
> svn copy trunk@a-long-time-ago branches/new-branch
>
> becomes:
>
> parent f572d396fae9206628714fb2ce00f72e94f2258f
>
> 2. Given a git commit, what is the corresponding Subversion revision
> number? For example, "git fetch" needs this information in order
> to get a first unfetched revision number when updating an existing
> clone of a Subversion repository.
>
> "git notes" is a mechanism for efficiently storing a mapping from git
> commit names to arbitrary data. For example, it can be used to cache
> the compiled form of some slow-to-compile source code, or it can be
> used to store reminders to a human that has reviewed these commits and
> wanted to scribble a little in the margin. A patch (in Dmitry's tree,
> not in git.git yet) teaches svn-fe to use the notes facility to store
> the mapping from git commit names to Subversion revision numbers,
> addressing problem (2) above. Tomas's human-friendly importer used
> the same trick.
>
> As you noticed, "git fast-import" has a facility that fits well for
> mapping in the other direction: a marks file can store an arbitrary
> mapping from numbers to objects (usually objects that were part of the
> import). svn-fe writes a mark for each Subversion revision it imports
> to address problem (1) above.
>
> Because "git notes" are stored in the git object db as native objects,
> they can be shared using the usual "git fetch" / "git push" commands
> as long as you specify the appropriate source and destination refs on
> the command line or in git's configuration file. Commands like "git
> rebase" that modify history also have some support for carrying notes
> along. By contrast, a marks file is just a flat text file and there
> is no standard facility for updating it when commit names change or
> sharing it using ordinary git transport.
>
> The marks-to-notes converter I wrote was a toy to show how the notes
> and marks can easily be kept in sync. If I remember correctly the
> last time this was discussed there was some feeling that when the two
> tables fall out of synch the notes should be considered authoritative
> and marks can be recomputed from them.
Oh, thats intersting, I haven't heard of git notes yet. (I should have greped
the Documentation ..).
Because of the possibility that one revision is transformed into two commits,
the bi-directional mapping has to support 1-to-n or probably n-to-n mappings,
I think. But this should be possible with these mechanisms.
>
> > Do we create two commits from one revision if it's some special case,
> > like modifying two branches at once?
>
> remote-svn-alpha and svn-fe do not currently split by branch at all so
> the problem doesn't come up.
>
> Yes, I think the only sane way to represent a Subversion revision that
> modifies multiple branches is with a git commit on each branch.
>
> [...]
>
> >> For example, there could be a parallel directory structure
> >>
> >> in the tree:
> >> foo/
> >>
> >> bar.c
> >>
> >> baz/
> >>
> >> qux.c
> >>
> >> .properties/
> >>
> >> foo.properties
> >> foo/
> >>
> >> bar.c.properties
> >>
> >> baz/
> >>
> >> qux.c.properties
> >>
> >> with properites for <path> stored at
> >> .properties/<path>.properties.
> >> This strawman scheme doesn't work if the repository being
> >> imported
> >> has any paths ending with ".properties", though. Ideas?
> >
> > This includes collecting which metadata we actually need to store? We
> > could probably collect a list of important svn properties.
>
> I imagined the importer just collecting all path properties, like "git
> svn" does in its .git/svn/refs/remotes/git-svn/unhandled.log. They're
> easy to iterate through on the svn side.
Ok, and it will be useful for pushing to svn in the future.
>
> > Is there a general policy how to store additional metadata for git's
> > helpers? I guess it would live somewhere in the .git dir. (.git/info/
> > ?)
>
> One simple design would be to keep properties in the "entire project"
> commit objects for internal use, since that's easy to share.
>
> I think David had a few other ideas. ;-)
Commit objects that are actually not commits but store metadata?
>
> [...]
>
> >> . tracing second-parent history using svn:mergeinfo properties.
> >
> > This is about detection when to create a git merge-commit, right?
>
> Yep. A goal would be to allow a person would be able to push a git
> merge to an svn repository, fetch from another machine, and get the
> same commit back.
>
> >> In other words, in the above list the strategy is:
> > .. still to come..
>
> Thanks for your thoughtfulness.
>
> Jonathan
Florian
next prev parent reply other threads:[~2012-04-14 20:17 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-19 14:42 GSoC intro Florian Achleitner
2012-03-19 21:31 ` Andrew Sayers
2012-03-20 12:25 ` Florian Achleitner
2012-03-20 13:19 ` David Barr
2012-03-21 21:16 ` Florian Achleitner
2012-03-26 11:06 ` Ramkumar Ramachandra
2012-03-27 13:53 ` Florian Achleitner
2012-04-02 8:30 ` GSOC Proposal draft: git-remote-svn Florian Achleitner
2012-04-02 11:00 ` Ramkumar Ramachandra
2012-04-02 20:57 ` Jonathan Nieder
2012-04-02 23:04 ` Jonathan Nieder
2012-04-03 7:49 ` Florian Achleitner
2012-04-03 18:48 ` Jonathan Nieder
2012-04-05 16:18 ` Tomas Carnecky
2012-04-02 22:17 ` Andrew Sayers
2012-04-02 22:29 ` Jonathan Nieder
2012-04-02 23:20 ` Andrew Sayers
2012-04-03 0:09 ` Jonathan Nieder
2012-04-03 21:53 ` Andrew Sayers
2012-04-03 22:21 ` Jonathan Nieder
2012-04-05 13:36 ` Florian Achleitner
2012-04-05 15:47 ` Dmitry Ivankov
2012-04-09 18:59 ` Stephen Bash
2012-04-10 17:17 ` Jonathan Nieder
2012-04-10 22:30 ` Andrew Sayers
2012-04-10 23:46 ` Jonathan Nieder
2012-04-11 19:09 ` Florian Achleitner
2012-04-14 22:57 ` Andrew Sayers
2012-04-11 15:51 ` Jakub Narebski
2012-04-11 15:56 ` Jonathan Nieder
2012-04-11 19:20 ` Florian Achleitner
2012-04-11 19:44 ` Dmitry Ivankov
2012-04-11 19:53 ` Jonathan Nieder
2012-04-11 22:43 ` Andrew Sayers
2012-04-12 9:02 ` Thomas Rast
2012-04-12 15:28 ` Florian Achleitner
2012-04-12 22:30 ` Andrew Sayers
2012-04-14 20:09 ` Florian Achleitner
2012-04-14 21:35 ` Andrew Sayers
2012-04-15 3:13 ` Stephen Bash
2012-04-13 19:19 ` Jonathan Nieder
2012-04-14 20:15 ` Florian Achleitner [this message]
2012-04-18 20:16 ` Florian Achleitner
2012-04-19 12:26 ` Florian Achleitner
2012-03-28 8:09 ` GSoC intro Miles Bader
2012-03-28 9:30 ` Dmitry Ivankov
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=2407098.F5IbgLFxk2@flomedio \
--to=florian.achleitner2.6.31@gmail$(echo .)com \
--cc=andrew-git@pileofstuff$(echo .)org \
--cc=artagnon@gmail$(echo .)com \
--cc=davidbarr@google$(echo .)com \
--cc=divanorama@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=jrnieder@gmail$(echo .)com \
--cc=srabbelier@gmail$(echo .)com \
--cc=tom@dbservice$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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