www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <santiago.g...@gmail.com>
Subject Re: svn:propchanges and git mirrors
Date Mon, 20 Apr 2009 11:40:20 GMT
El jue, 16-04-2009 a las 17:50 -0700, Paul Querna escribió: 
> On Thu, Apr 16, 2009 at 1:19 PM, Santiago Gala <santiago.gala@gmail.com> wrote:
> > I guess we are aware that thia:
> >
> >
> >> Modified property: svn:log
> >>
> >> Modified: svn:log at Wed Apr 15 23:16:15 2009
> >> ------------------------------------------------------------------------------
> >> --- svn:log (original)
> >> +++ svn:log Wed Apr 15 23:16:15 200
> > ...
> >>
> > happens from time to time, and that it impacts git mirrors in the sense
> > that either:
> > - the mirror's log will diverge from the svn log in time, or
> > - someone has to reimport from this commit on, which play havoc
> >
> > This is due to the fact that in svn the commit is not the atomic object
> > stored, like in git. In git rewriting history means always new commits,
> > and log is included as commit info.
> >
> > Do we have any solution or practice for this behavior? it happens from
> > time to time in shindig and other repositories  I have seen, and I don't
> > know how to deal with it for published mirrors. Even for unpublished
> > ones, I'm not sure there is a simple way to rebase on top of the
> > modified revision.
> Propogating a change in a non-versioned property in subversion is very hard.
> svnsync can run into the same problems.
> IMO, the best way is to 'log' these changes to a file when they
> happen, just a timestamp, revision, and properties changed.
> Then a script could check this once on a crontab and force resync of
> single revisions......
> For svnsync this would work, no idea how one would do this in git :)

For git, the main problem is that a git commit id is formed by taking
the SHA1 of the repository tree, plus the log message, a small set of
metadata, and *the id of the parent(s)*. Which means that all commits
descending from one that changes *must* change, as their commit id
changes recursively.

So, not only one has to notice the change, but also fixing the change
means changing all descendants, which means any branch rooted in a
descendant will change, and people with local changes would need to
extract all the branches as patches and patch them back on top of the
new bases (this is what "rebasing" means), or similar intrusive things.

My email was a mixture of warning so that we are aware that mirrors get
out of sync when properties are changed, and also or brainstorming to
see if we can find mixtures of practices and policies to deal with those


View raw message