Daniel Barkalow [off-list ref] writes:
On Wed, 25 Mar 2009, Junio C Hamano wrote:
quoted
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.
I am afraid that won't fly; my comment that started this subthread was not
about your "import" but was about your "export" part. It is about sending
the git branch to the other end, which is allowed to rewrite what we send
and force us to modify our history.
On Wed, 25 Mar 2009, Junio C Hamano wrote:
Daniel Barkalow [off-list ref] writes:
quoted
On Wed, 25 Mar 2009, Junio C Hamano wrote:
quoted
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.
I am afraid that won't fly; my comment that started this subthread was not
about your "import" but was about your "export" part. It is about sending
the git branch to the other end, which is allowed to rewrite what we send
and force us to modify our history.
It can rewrite what we send, but if we're not reimporting it, we don't
care what it's done. All we care about is that when we ignore the
rewriting, git-vcs-* can still export more changes from our version of the
history.
That is, if we push X, which gets rewritten to X' (but we ignore that),
and we then push Y, whose parent is X (not X'), a high-quality git-vcs
backend will be reliably able to accept the second push, just as if we'd
created a Y' based on X'. And by "high-quality", I mean some testable
capability with a better name.
-Daniel
*This .sig left intentionally blank*