svn:propchanges and git mirrors

[Santiago Gala <sa...@gmail.com>]

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.

Regards
Santiago

Re: svn:propchanges and git mirrors

[Santiago Gala <sa...@gmail.com>]

El jue, 16-04-2009 a las 17:50 -0700, Paul Querna escribió: 
> On Thu, Apr 16, 2009 at 1:19 PM, Santiago Gala <sa...@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
changes.

Regards
Santiago

Re: svn:propchanges and git mirrors

[Paul Querna <pa...@querna.org>]

On Thu, Apr 16, 2009 at 1:19 PM, Santiago Gala <sa...@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 :)

Re: svn:propchanges and git mirrors

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Thu, Apr 16, 2009 at 10:19 PM, Santiago Gala <sa...@gmail.com> wrote:
> Do we have any solution or practice for this behavior?

We can always recreate the related Git mirror when asked. That will
cause some breakage for downstream users, but I guess that a heads-up
message to the relevant dev@ list should avoid most trouble.

BR,

Jukka Zitting