Oops: Recent changes were really part of QPID-4180

[Andrew Stitcher <as...@redhat.com>]

Many apologies, I got a bit too excited and submitted a bunch of changes
without attaching the issue reference. And now Jira itself is down so I
can't even add a reference at that end!

Anyway changes r1371774 & r1371775 were the changes to close out
QPID-4180.

Sorry

Andrew



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

Re: Oops: Recent changes were really part of QPID-4180

[Robbie Gemmell <ro...@gmail.com>]

Ok, I think the key differences in our worklows is that I dont tend to
push/pull between repos much and only normally merge between local branches
and/or the remote svn branches before dcommiting, and as a result havent
run into the merge issues you have because the hashes differing doesnt
really matter then.

I seem to recall from previous reading that the different git mirrors (
git.apache.org and github) are actually synced differently, so the
behaviour probably also depends on which one you use and how you use it (I
only use them for the initial clone, afterwards I'm usually just rebasing
against svn rather than the mirror).

Robbie

On 10 August 2012 20:21, Andrew Stitcher <as...@redhat.com> wrote:

> On Fri, 2012-08-10 at 20:05 +0100, Robbie Gemmell wrote:
> > I've seen this mentioned on here in the past, either by yourself or maybe
> > Alan, and I'm a bit curious as to what actually happens?
> >
> > I cant say I have seen it cause me any problems so far when using git-svn
> > (git cloned from the git mirror, then git-svn initialised and rebased
> > against svn). Indeed, git-svn doesnt seem to care at all when an incoming
> > commit log doesnt match the message for a local commit of the same
> changes,
> > which is a situation I often tend to provoke in checkouts im using by
> > changing a message before dcommitting it from another workspace I have
> > applied it to. Do you have any special sauce in your git workflow? not
> > using git-svn?
>
> I think our definitions of screwed up may be different.
>

> If you rewrite svn history then anyone who has git mirrored on the
> previous history gets an entirely different branch from someone who has
> history based on the the rewritten history. They will diverge at the
> rewrite. In effect git branches are based on a hash of the changes and
> the comments. So you lose the ability to simply pull changes from one
> repo to the other without some (usually trivial but irritating) merging
> going on. We've had this happen in the past to the qpid tree and it
> usually takes a while to figure out what's going on and why there are
> merges where you didn't expect them.
>
> This situation won't stop the git-svn mirror from working it will just
> make the history in some repos different from in some others and make
> them somewhat incompatible (ie there will be different SHAs for the same
> upstream change.)
>
> I'll note that if you get the change in before the git mirror gets the
> changes then all is well, because git never sees the old changes at all,
> but it's not clear to me whether the mirroring process is on a fixed
> interval basis or whether it is on demand driven by the changes
> themselves.
>
> Andrew
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>

Re: Oops: Recent changes were really part of QPID-4180

[Andrew Stitcher <as...@redhat.com>]

On Fri, 2012-08-10 at 20:05 +0100, Robbie Gemmell wrote:
> I've seen this mentioned on here in the past, either by yourself or maybe
> Alan, and I'm a bit curious as to what actually happens?
> 
> I cant say I have seen it cause me any problems so far when using git-svn
> (git cloned from the git mirror, then git-svn initialised and rebased
> against svn). Indeed, git-svn doesnt seem to care at all when an incoming
> commit log doesnt match the message for a local commit of the same changes,
> which is a situation I often tend to provoke in checkouts im using by
> changing a message before dcommitting it from another workspace I have
> applied it to. Do you have any special sauce in your git workflow? not
> using git-svn?

I think our definitions of screwed up may be different.

If you rewrite svn history then anyone who has git mirrored on the
previous history gets an entirely different branch from someone who has
history based on the the rewritten history. They will diverge at the
rewrite. In effect git branches are based on a hash of the changes and
the comments. So you lose the ability to simply pull changes from one
repo to the other without some (usually trivial but irritating) merging
going on. We've had this happen in the past to the qpid tree and it
usually takes a while to figure out what's going on and why there are
merges where you didn't expect them.

This situation won't stop the git-svn mirror from working it will just
make the history in some repos different from in some others and make
them somewhat incompatible (ie there will be different SHAs for the same
upstream change.)

I'll note that if you get the change in before the git mirror gets the
changes then all is well, because git never sees the old changes at all,
but it's not clear to me whether the mirroring process is on a fixed
interval basis or whether it is on demand driven by the changes
themselves.

Andrew



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

Re: Oops: Recent changes were really part of QPID-4180

[Robbie Gemmell <ro...@gmail.com>]

I've seen this mentioned on here in the past, either by yourself or maybe
Alan, and I'm a bit curious as to what actually happens?

I cant say I have seen it cause me any problems so far when using git-svn
(git cloned from the git mirror, then git-svn initialised and rebased
against svn). Indeed, git-svn doesnt seem to care at all when an incoming
commit log doesnt match the message for a local commit of the same changes,
which is a situation I often tend to provoke in checkouts im using by
changing a message before dcommitting it from another workspace I have
applied it to. Do you have any special sauce in your git workflow? not
using git-svn?

Robbie

On 10 August 2012 19:35, Andrew Stitcher <as...@redhat.com> wrote:

> On Fri, 2012-08-10 at 19:24 +0100, Gordon Sim wrote:
> > ...
> >
> > You can retrospectively edit the commit log for svn if you like.
>
> I hope that isn't something many people do: It has the strong
> possibility to totally screw up the synchronisation with git depending
> on exactly when the synchronising is done.
>
> So although it would look ok in svn it be end up a mess in git.
>
> Personally I'm more dependent on git for my work, so this bothers me a
> lot.
>
> Andrew
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>

Re: Oops: Recent changes were really part of QPID-4180

[Andrew Stitcher <as...@redhat.com>]

On Fri, 2012-08-10 at 19:24 +0100, Gordon Sim wrote:
> ...
> 
> You can retrospectively edit the commit log for svn if you like.

I hope that isn't something many people do: It has the strong
possibility to totally screw up the synchronisation with git depending
on exactly when the synchronising is done.

So although it would look ok in svn it be end up a mess in git.

Personally I'm more dependent on git for my work, so this bothers me a
lot.

Andrew



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

Re: Oops: Recent changes were really part of QPID-4180

[Gordon Sim <gs...@redhat.com>]

On 08/10/2012 07:05 PM, Andrew Stitcher wrote:
> Many apologies, I got a bit too excited and submitted a bunch of changes
> without attaching the issue reference. And now Jira itself is down so I
> can't even add a reference at that end!
>
> Anyway changes r1371774 & r1371775 were the changes to close out
> QPID-4180.

You can retrospectively edit the commit log for svn if you like.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org