On Wed, 25 Mar 2009, Junio C Hamano wrote: > Suppose a project used to use subversion, but it migrated to git (not an > unheard-of scenario these days, I hope). The git repository now is the > authoritative one, all the development happens on this side. > > But in order to help: > > - people who have established their workflow to follow the project > (e.g. not necessarily contributing anything back, but just doing > regular "svn update"); > > - people who have leftover local changes from the subversion days; and > > - other project infrastracture (e.g. trac) that the project hasn't > managed to interface to the new git repository yet; > > the project decides to keep feeding recent updates to the subversion > repository that used to be authoritative, even though it is now declared > read-only (i.e. the only update comes from the git end). Actually, this is easy: just configure the git repo to not fetch anything from the no-longer-authoritative subversion repository. git-vcs-svn would waste a bunch of time reimporting what it exported, but it wouldn't actually do anything with it (since it doesn't even have tracking refs to update). It could, of course, be optimized to avoid reimporting if it doesn't need to. > My understanding is that the above scenario would not work if git-vcs-svn > rewrites commits when git exports to svn, and existing git-svn two-way > interface using its "dcommit" may have exactly the same issue. > > The reason I brought this up was to involve people who have already faced > this issue with git-svn in the discussion to see if we can avoid it by > doing somethink similar to clever tricks they are using in their git-svn > workflow, if there are some. Perhaps your paragraph below may be one of > those clever tricks, but there may be others. The harder problem is that you can only push history that the remote system will be able to represent. In the same way that git wants your push to be a fast-forward, svn wants your push to not contain any merges (and p4 and svn both want your push to not contain parallel development pushed to a single branch). Rewriting the history to conform to the destination's requirements is most of what dcommit does, I believe. I think that, in this use case, the right thing is to have a config option for git-vcs-svn to tell it to collapse the problematic commits (or maybe collapse all commits in a push). That would make the svn history export like the reflog, which is all linear and simple anyway, and probably sufficient for the above users of the old repository. -Daniel *This .sig left intentionally blank* -- 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
