svn history getting lost?

[Lei Zhang]

I noticed in svn, base/memory/singleton.h only has 1 log entry - the
move from base/singleton.h. All previous history no longer shows up in
svn log. Ditto for lots of other files that have been moved around.
IIRC, svn mv will keep the file history around. Is this due to a bad
interaction between git mv and svn?

[Evan Martin]

It seems likely (the code review has a git patch), but as you can see
on the review the files were noted as moves ("A +" in svn-ese).
David, did you do anything strange when you committed this?

(Note that you can use "git log -M --follow base/memory/singleton.h"
to reconstruct more history if you happen to have a git checkout
handy.)

[David Levin]

On Tue, May 24, 2011 at 5:54 PM, Evan Martin <ev...@chromium.org> wrote:

On Tue, May 24, 2011 at 5:37 PM, Lei Zhang <the...@chromium.org> wrote:
> I noticed in svn, base/memory/singleton.h only has 1 log entry - the
> move from base/singleton.h. All previous history no longer shows up in
> svn log. Ditto for lots of other files that have been moved around.
> IIRC, svn mv will keep the file history around. Is this due to a bad
> interaction between git mv and svn?

It seems likely (the code review has a git patch), but as you can see
on the review the files were noted as moves ("A +" in svn-ese).
David, did you do anything strange when you committed this?

Not as far as I know. 

For the changes, I did a git mv followed by changes in the files (which were needed due to the moves).

For the commit, (to my memory) I did git cl dcommit.

If there was anything I did wrong, I'd be happy to know for the future.

thanks,

dave

[Marc-Antoine Ruel]

Le 25 mai 2011 00:19, David Levin <le...@chromium.org> a écrit :

On Tue, May 24, 2011 at 5:54 PM, Evan Martin <ev...@chromium.org> wrote:

On Tue, May 24, 2011 at 5:37 PM, Lei Zhang <the...@chromium.org> wrote:
> I noticed in svn, base/memory/singleton.h only has 1 log entry - the
> move from base/singleton.h. All previous history no longer shows up in
> svn log. Ditto for lots of other files that have been moved around.
> IIRC, svn mv will keep the file history around. Is this due to a bad
> interaction between git mv and svn?

It seems likely (the code review has a git patch), but as you can see
on the review the files were noted as moves ("A +" in svn-ese).
David, did you do anything strange when you committed this?

Not as far as I know. 

For the changes, I did a git mv followed by changes in the files (which were needed due to the moves).

For the commit, (to my memory) I did git cl dcommit.

If there was anything I did wrong, I'd be happy to know for the future.

No you didn't do anything wrong. Maybe we could use git svn dcommit --find-copies-harder so it'd try harder to reconstruct the svn metadata.

That's a reason I've yet to support moved files in the commit queue as I'm unsure about breaking the svn history. If we finally decide to move to git, the point is moot since git simply discards the metadata and we could simply forego the svn history anyway right now. That would make the commit queue much more usable right now.

Any opinion?

M-A

[John Abd-El-Malek]

On Wed, May 25, 2011 at 7:26 AM, Marc-Antoine Ruel <mar...@chromium.org> wrote:

Le 25 mai 2011 00:19, David Levin <le...@chromium.org> a écrit :

On Tue, May 24, 2011 at 5:54 PM, Evan Martin <ev...@chromium.org> wrote:

On Tue, May 24, 2011 at 5:37 PM, Lei Zhang <the...@chromium.org> wrote:
> I noticed in svn, base/memory/singleton.h only has 1 log entry - the
> move from base/singleton.h. All previous history no longer shows up in
> svn log. Ditto for lots of other files that have been moved around.
> IIRC, svn mv will keep the file history around. Is this due to a bad
> interaction between git mv and svn?

It seems likely (the code review has a git patch), but as you can see
on the review the files were noted as moves ("A +" in svn-ese).
David, did you do anything strange when you committed this?

Not as far as I know. 

For the changes, I did a git mv followed by changes in the files (which were needed due to the moves).

For the commit, (to my memory) I did git cl dcommit.

If there was anything I did wrong, I'd be happy to know for the future.

No you didn't do anything wrong. Maybe we could use git svn dcommit --find-copies-harder so it'd try harder to reconstruct the svn metadata.

Are you saying that anyone who moves files using git will cause us to lose svn history?  That seems really unfortunate and should be avoided.  I find svn history very valuable.

That's a reason I've yet to support moved files in the commit queue as I'm unsure about breaking the svn history. If we finally decide to move to git, the point is moot since git simply discards the metadata and we could simply forego the svn history anyway right now. That would make the commit queue much more usable right now.

Any opinion?

Just to be clear, are you asking if it's ok to break svn history?  If so, I definitely don't think so. 

M-A

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[John Abd-El-Malek]

On Wed, May 25, 2011 at 8:48 AM, John Abd-El-Malek <j...@chromium.org> wrote:

On Wed, May 25, 2011 at 7:26 AM, Marc-Antoine Ruel <mar...@chromium.org> wrote:

Le 25 mai 2011 00:19, David Levin <le...@chromium.org> a écrit :

On Tue, May 24, 2011 at 5:54 PM, Evan Martin <ev...@chromium.org> wrote:

On Tue, May 24, 2011 at 5:37 PM, Lei Zhang <the...@chromium.org> wrote:
> I noticed in svn, base/memory/singleton.h only has 1 log entry - the
> move from base/singleton.h. All previous history no longer shows up in
> svn log. Ditto for lots of other files that have been moved around.
> IIRC, svn mv will keep the file history around. Is this due to a bad
> interaction between git mv and svn?

It seems likely (the code review has a git patch), but as you can see
on the review the files were noted as moves ("A +" in svn-ese).
David, did you do anything strange when you committed this?

Not as far as I know. 

For the changes, I did a git mv followed by changes in the files (which were needed due to the moves).

For the commit, (to my memory) I did git cl dcommit.

If there was anything I did wrong, I'd be happy to know for the future.

No you didn't do anything wrong. Maybe we could use git svn dcommit --find-copies-harder so it'd try harder to reconstruct the svn metadata.

Are you saying that anyone who moves files using git will cause us to lose svn history?  That seems really unfortunate and should be avoided.  I find svn history very valuable.

btw I looked for changes that had a file move, from other git users, to see if this always happens.  I picked

http://src.chromium.org/viewvc/chrome?view=rev&revision=57434

and it looks like moved files have their history intact, i.e.

http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/prefs/pref_set_observer.cc?limit_changes=0&view=log&pathrev=57434

So it would be good if the correct git commands are tracked down for future moves.

[Craig Schlenter]

On Wed, May 25, 2011 at 5:48 PM, John Abd-El-Malek <j...@chromium.org> wrote:
>
> On Wed, May 25, 2011 at 7:26 AM, Marc-Antoine Ruel <mar...@chromium.org>
> wrote:
>>
>> Le 25 mai 2011 00:19, David Levin <le...@chromium.org> a écrit :
>>>
>>>
>>> On Tue, May 24, 2011 at 5:54 PM, Evan Martin <ev...@chromium.org> wrote:
>>>>
>>>> On Tue, May 24, 2011 at 5:37 PM, Lei Zhang <the...@chromium.org> wrote:
>>>> > I noticed in svn, base/memory/singleton.h only has 1 log entry - the
>>>> > move from base/singleton.h. All previous history no longer shows up in
>>>> > svn log. Ditto for lots of other files that have been moved around.
>>>> > IIRC, svn mv will keep the file history around. Is this due to a bad
>>>> > interaction between git mv and svn?
>>>>
>>>> It seems likely (the code review has a git patch), but as you can see
>>>> on the review the files were noted as moves ("A +" in svn-ese).
>>>> David, did you do anything strange when you committed this?
>>>
>>> Not as far as I know.
>>> For the changes, I did a git mv followed by changes in the files (which
>>> were needed due to the moves).
>>> For the commit, (to my memory) I did git cl dcommit.
>>> If there was anything I did wrong, I'd be happy to know for the future.
>>
>> No you didn't do anything wrong. Maybe we could use git svn dcommit
>> --find-copies-harder so it'd try harder to reconstruct the svn metadata.
>
> Are you saying that anyone who moves files using git will cause us to lose
> svn history?  That seems really unfortunate and should be avoided.  I find
> svn history very valuable.

You probably know this but maybe this helps someone - you can get the svn
history prior to the move - the command below shows the history for the
moved singleton.h file Lei was referring to:

svn log svn://.../chrome/trunk/src/base/singleton.h@79523

I've used a revision number one less than where the log "stopped" on trunk
for singleton.h and you have to figure out the original path of the
file by looking
at the svn log -v output and/or the diff output for the earliest log
entry for the
current singleton.h.

The git --follow stuff is of course much less painful...

--Craig

[John Abd-El-Malek]

Thanks.  Yes this is possible, but is inconvenient.  Especially when looking through viewvc (where it's also possible).

 

The git --follow stuff is of course much less painful... 

--Craig

[Jay Soffian]

On Wed, May 25, 2011 at 11:56 AM, John Abd-El-Malek <j...@chromium.org> wrote:
> So it would be good if the correct git commands are tracked down for future
> moves.

From the git svn man page:

"Committing renamed and copied files is fully supported if they're
similar enough for git to detect them"

I suspect that for some reason the file was not detected as renamed.
It has a 98% similarity though from the old to new name:

$ git diff --name-status dea8348e57^ dea8348e57 -- base/singleton.h
base/memory/singleton.h
R098 base/singleton.h base/memory/singleton.h

Perhaps you have to explicitly enable rename detection, but I would've
thought git svn would do that automatically. In any case, I fly with:

$ git config --global diff.renames copies
$ git config --global diff.renameLimit 0

j.

[Jay Soffian]

On Wed, May 25, 2011 at 2:09 PM, Jay Soffian <jayso...@gmail.com> wrote:
> Perhaps you have to explicitly enable rename detection, but I would've
> thought git svn would do that automatically. In any case, I fly with:
>
> $ git config --global diff.renames copies
> $ git config --global diff.renameLimit 0

Looking at the git-svn source, it does pass -C to diff-tree, which
enables both copy and rename detection (so the config options above
should not be needed). The diff-tree options can be further tuned via
git svn options -C, -l, and --find-copies-harder, all of which are
passed through to diff-tree.

The argument to -C specifies the pre/post similarity and defaults to 50%

The -l argument limits the potential rename/copy targets and defaults to 400.

The --find-copies-harder argument tells git to look at the entire
tree, as opposed to just modified files, to fetch rename sources.

All of this is to say, I don't understand why this file wasn't
detected as renamed. There's not enough information in the final
commit, though perhaps git reflog on the original repo where git-svn
was run would be revealing.

j.