Am 19.05.2010 um 18:33 schrieb Niels Reedijk:
On 19 May 2010 17:01, Andreas Färber <andreas.faerber@xxxxxx> wrote:Am 18.05.2010 um 11:09 schrieb Niels Reedijk:My next developer-tools project is going to be an hg<->svn bridge. I hope to deliver a proof-of-concept soon (which would then also be useful for a git<->svn bridge). The difference from hgsvn andhgsubversion is that it is all done server-side, meaning the end userdoes not have to bother with the logistics that it all involves.Is there really a need to do this for git?Yes there is. All solutions depend on a personal git <-> svn connection.
This means that everybody is creating his own unique repository, with unique changeset ids.
Changeset hashes will be identical if the changes and commit messages(?) are identical. That is, the SVN server needs to be the same since it is mentioned in the commit message.
So iiuc the only "uniqueness" arises if I use svn://svn.berlios.de and a committer uses svn+ssh://user@xxxxxxxxxxxxxxxx (or a local SVN mirror). Then r12345 will have different hashes - but since no one seemed to like hashes here... ;-)
That means that between git trees the changesets cannot be exchanged, which takes away one of the advantages of a distributed system.
In which way "cannot be exchanged"? I doubt that git-am cares as long as the patch applies, I'm pretty sure I've used it successfully even with local patches applied (so different base hash). And git-rebase should work fine, ignoring duplicate changes.
Andreas
