* [ANNOUNCE] git-as-svn: subversion frontend server for git repository
@ 2014-09-09 11:19 Marat Radchenko
2014-09-09 16:49 ` Junio C Hamano
0 siblings, 1 reply; 4+ messages in thread
From: Marat Radchenko @ 2014-09-09 11:19 UTC (permalink / raw)
To: git; +Cc: marat, bozaro
Some time ago I complained [1] about troubles using Git
on a project with high ratio of non-programmers.
Since then, a conclusion was made: Git is too complex.
While Git provides many nice advanced stuff, its simplest
workflow isn't simple enough.
So we examined other options:
* Splitting project in two repos (Git + SVN). It was
thought to be the worst idea because we lost commit
atomicity
* Use GitHub SVN integration [2]. Rejected due to security
considerations: our closed-source project isn't allowed to be
hosted outside.
* Use GitHub Enterprise: rejected due to pricing
* Use SubGit [3]: rejected because of its architecture.
Then, a lost'n'forgotten git_svn_server [4] was found. After playing
with it, we found out that its approach can work, though several
decisions (Python and extensive forking of `git`) made it very slow.
So we thought "we're programmers, after all".
And that's when *git-as-svn* [5] was born. It is a daemon that sits
on top of Git repository and talks svn:// protocol.
Features supported:
* checkout/update
* log
* blame
* commit (!)
* rename detection (though a bit slow yet)
* svn:eol-style
* Git pre-receive hooks
* simple or LDAP authentication
* partial checkout
* sparse working copy (svn --depth/--set-depth)
* git submodules
Current limitations:
* Only a single Git branch from a single repository
* Needs at least one commit in Git
* Parses whole history on startup and doesn't cache it anywhere
* You must not do 'inverted merges'. Old HEAD must be reachable from
new HEAD by first-parent traversal.
[1]: http://marc.info/?l=git&m=139866660018802
[2]: https://help.github.com/articles/support-for-subversion-clients
[3]: http://subgit.com/
[4]: http://git.q42.co.uk/git_svn_server.git
[5]: https://github.com/bozaro/git-as-svn/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ANNOUNCE] git-as-svn: subversion frontend server for git repository
2014-09-09 11:19 [ANNOUNCE] git-as-svn: subversion frontend server for git repository Marat Radchenko
@ 2014-09-09 16:49 ` Junio C Hamano
2014-09-09 18:57 ` Marat Radchenko
0 siblings, 1 reply; 4+ messages in thread
From: Junio C Hamano @ 2014-09-09 16:49 UTC (permalink / raw)
To: Marat Radchenko; +Cc: git, bozaro
Marat Radchenko <marat@slonopotamus.org> writes:
> Some time ago I complained [1] about troubles using Git
> on a project with high ratio of non-programmers.
> ...
> Then, a lost'n'forgotten git_svn_server [4] was found.
> ...
Interesting.
> Current limitations:
> ...
> * You must not do 'inverted merges'. Old HEAD must be reachable from
> new HEAD by first-parent traversal.
I am not sure what you mean by this to properly assess how
significant this limitation is. Care to draw a simple picture?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ANNOUNCE] git-as-svn: subversion frontend server for git repository
2014-09-09 16:49 ` Junio C Hamano
@ 2014-09-09 18:57 ` Marat Radchenko
2014-09-09 19:30 ` Junio C Hamano
0 siblings, 1 reply; 4+ messages in thread
From: Marat Radchenko @ 2014-09-09 18:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, bozaro, marat
On Tue, Sep 09, 2014 at 09:49:03AM -0700, Junio C Hamano wrote:
> Marat Radchenko <marat@slonopotamus.org> writes:
>
> > Some time ago I complained [1] about troubles using Git
> > on a project with high ratio of non-programmers.
> > ...
> > Then, a lost'n'forgotten git_svn_server [4] was found.
> > ...
>
> Interesting.
Actually, no. As I said, git_svn_server made several ineffective
architectural choices. It can be viewed as a proof-of-concept work though.
> > Current limitations:
> > ...
> > * You must not do 'inverted merges'. Old HEAD must be reachable from
> > new HEAD by first-parent traversal.
>
> I am not sure what you mean by this to properly assess how
> significant this limitation is. Care to draw a simple picture?
SVN doesn't support nonlinear history (except merge-info crutch).
Thus, we only expose "main" history line to SVN where "main" means
"reachable through first-parent traversal from branch tip".
To keep SVN history consistent, commits that once became visible to SVN
have to remain visible. This limitation will be removed when git-as-svn
gets persistent storage and will be able to remember what *was* main line.
Imagine you had following history:
--- time --->
A -- B -- C
Now you merge (via Git) a feature branch:
A -- B -- C -- G
\ /
D -- E --- F
For SVN, history will look this way:
A -- B -- C -- F
We might introduce merge-info support for this one day.
And now the *bad* case. You have the same initial history but do *inverted merge*:
A -- D -- E -- F -- G'
\ /
B -- C ---------/
^
|
Previous branch tip
That's where things brake because for SVN, history transforms from
A -- B -- C
to
A -- D -- E -- F -- G'
And all users who checked out revisions B & C get their working copies screwed.
This also means that push --force also must not be performed.
Quoting my initial post [1] about inverted merges (you might call them
"merges with swapped parents").
> I call it "swapped/reverse merge problem".
>
> In short:
> 1. Hack, hack, hack
> 2. Commit
> 3. Push, woops, reject (non-ff)
> 4. Pull
> 5. Push
>
> The root of evil is step #4 that creates a merge commit with "swapped" parents -
> local commits become first parent, remote commits become second. If one would want to
> make proper parent order, he would have to: 1. git fetch
> 2. git checkout origin/master -b tmp
> 3. git merge master
> 4. git push
> 5. git checkout master
> 6. git merge origin/master
> 7. git branch -d tmp
>
> And all this branch dance produces exactly the same commit (content-wise) as simple
> "pull, push" sequence with the only difference in parent order. And things become
> even worse if comeone pushes more commits to remote repo while you perform this
> dance.
>
> We can't expect all developers (especially, designers and artist) to do it. They
> don't want to use branches and just work on mainline. This is especially important on
> early development stages when new features (that designers' work depends upon) are
> added every day.
>
> Additionally, many git-related tools depend on first-parent convention and show wrong
> graphs/diffs.
[1] http://marc.info/?l=git&m=139866660018802
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ANNOUNCE] git-as-svn: subversion frontend server for git repository
2014-09-09 18:57 ` Marat Radchenko
@ 2014-09-09 19:30 ` Junio C Hamano
0 siblings, 0 replies; 4+ messages in thread
From: Junio C Hamano @ 2014-09-09 19:30 UTC (permalink / raw)
To: Marat Radchenko; +Cc: git, bozaro
Marat Radchenko <marat@slonopotamus.org> writes:
>> > * You must not do 'inverted merges'. Old HEAD must be reachable from
>> > new HEAD by first-parent traversal.
>>
>> I am not sure what you mean by this to properly assess how
>> significant this limitation is. Care to draw a simple picture?
>
> SVN doesn't support nonlinear history (except merge-info crutch).
> ...
> And now the *bad* case. You have the same initial history but do *inverted merge*:
That is a bad way to answer a question that asks "what do you mean
by an 'inverted merge', which is not in our normal lexicon?" ;-)
You must not merge the current tip of SVN server *into* the
work you did on top of a past state you obtained from the
SVN server. Check out the current state from the SVN side,
and merge your work into it instead.
or something like that is what people would understand without
introducing a new/unused word to the world. And
> A -- D -- E -- F -- G'
> \ /
> B -- C ---------/
> ^
> |
> Previous branch tip
this illustrates the topology you meant reasonably well, especially
if you marked D, E and F as "your own work" (as opposed to what the
server side did in the meantime while you worked, i.e. B and C).
Thanks for a clarification.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-09-09 19:30 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-09 11:19 [ANNOUNCE] git-as-svn: subversion frontend server for git repository Marat Radchenko
2014-09-09 16:49 ` Junio C Hamano
2014-09-09 18:57 ` Marat Radchenko
2014-09-09 19:30 ` Junio C Hamano
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).