Ramkumar Ramachandra wrote:
> Also, since we're aiming for a two-way mapping, it's going to be
> significantly more challenging: we will need a mapping function that
> can be inverted perfectly.
Sounds interesting! Let's see how much I can narrow scope/dash hopes.
:)
First of dreams is the possibility of using git as a replacement for
svnsync, to get semantically identical SVN repositories like so:
[...]
> SVN repository 1 -> dumpfile -> Git repository
> Git repository -> dumpfile' -> SVN repository 2
in a way that svn tools can look at repo 2 as a basically perfect
replacement for repo 1. This means copying svnsync properties,
rename tracking info, svn properties, etc.
I. Some people might want that, and I wouldn't want to stop them
trying (maybe using notes, perhaps even the mythical tree-based
form) but I'm not interested in it at all. Is it a goal for you?
Second would be the possibility of using an SVN repository as a
conduit for communication between git repositories:
Git repository 1 -> fast-export stream -> SVN repository
SVN repository -> dumpfile -> Git repository 2
II. It would be super cool to be able to transport arbitrary git
objects via svn (maybe using custom properties and fabricated
temporary branches named after the first commit after a fork
point). Perhaps some people could host git projects on Google
Code this way. Is that a goal?
Git 1 -> SVN 1 -> Git 2 -> SVN 2 -> Git 3
III. Perhaps only the subset of git objects with certain properties
should be considered safe to transport via an SVN repository
(e.g.:
- author matches committer
- timestamps are New York time
- author address is of the format username <username>
- filenames are valid UTF-8
). And maybe any existing git repository can be painlessly
transformed to consist only of such commits. Is that a model
to strive for?
SVN 1 -> Git 1 -> SVN 2 -> Git 2 -> SVN 3
IV. Maybe only some svn changes would be considered safe to
transport via git: no weird properties, no tracked renames
not involved in branches/merges, all branches named after the
git commit id of the first rev after the fork point, ...
And maybe any existing svn repository can be painlessly
transformed to consist only of such revisions. Is that a goal?
(As you might have guessed, my answers are "no, no, no, and no, at
least at first, but it is fun to imagine how a person would go about
achieving these things anyway").
Hope that clarifies something,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html