New KMix version about to be checked in - a complete replacement of the source tree

[Colin Guthrie]

'Twas brillig, and Christian Esken at 23/08/10 15:36 did gyre and gimble:
> On Monday 23 August 2010 11:55:23 Colin Guthrie wrote:
>> 'Twas brillig, and Christian Esken at 22/08/10 23:40 did gyre and gimble:
>>> On Tuesday 22 June 2010 21:06:04 Christian Esken wrote:
>>>> Hello,
>>>
>>> I have a "completely new" KMix version to check in. "Completely new" is
>>> referring to two facts: - A lot of cleanup
>>>
>>> -The sourcefiles are distributed in completely new directories, namely:
>>>   apps/
>>>   core/
>>>   gui/
>>>   backend/
>>>>
>>>> [1] The work branch is /branches/work/kmix/. If you have changes for
>>>> KMix, especially bugfixes, please let me know, so that I can integrate
>>>> that in the work branch.
>>>
>>> I didn't receive any changes, thus i will "replace" the trunk source tree
>>> by my work branch without having to act with caution. I will have enogh
>>> trouble with SVN tree conflicts, I fear.  Any good advice on handling
>>> SVN tree conflicts are highly appreciated. Anyone?
>>
>> Well, personally I would have used git-svn rather than an svn branch as
>> that way you can "rebase" your changes to the trunk version and then
>> "dcommit" the results any time.
>>
>> While it results in a "commit flood" it's a good way of keeping the
>> history of the changes in the mailing trunk commit log rather than lost
>> in a branch.
>  
>> Theoretically you can still use git svn quite easily by importing the
>> branch svn to git at the point it was branched, pulling in all the changes

> I have not yet worked with git. But lets try. That would be http://websvn.kde.org/view=revision&revision=1129222

Be warned: There may be a better way. I've done this before with
git-svn, so I kinda know how to work with it, but it may not be the most
optimal way.


As well as the way below, an alternative would be to bring all the
changes made in trunk since your branch to the branch and rebase your
work. It all amounts to the same thing, but "rebasing" is perhaps a
clearer process to work with and thus I'll describe that here:

So:

[colin at jimmy christian]$ git svn clone -r 1129222
svn+ssh://svn.kde.org/home/kde/branches/work/kmix
Initialized empty Git repository in
/home/colin/Development/Personal/KDE/christian/kmix/.git/
	A	osdwidget.h
...
r1129222 = ca5aa67b7662e9158831a7c582c338389940f19a (refs/remotes/git-svn)
Checked out HEAD:
  svn+ssh://svn.kde.org/home/kde/branches/work/kmix r1129222
[colin at jimmy christian]$ cd kmix/
[colin at jimmy kmix (master)]$ git tag -m "The Start" beginning
[colin at jimmy kmix (master)]$ git svn rebase
	A	kmixd.cpp
...
	M	apps/kmix.h
r1166782 = a948eeefc2afe2fd29b5726f5feb5170ea812972 (refs/remotes/git-svn)
First, rewinding head to replay your work on top of it...
Fast-forwarded master to refs/remotes/git-svn.
[colin at jimmy kmix (master)]$ git format-patch -o .. beginning..HEAD

OK, so now you have your version in handy single commit files. You
correctly noted that some are actually empty (the svn property change
commits), so just trash those two.




Now we leave this and move over to a fresh clone of trunk.

First we need to calculate the revision in trunk prior to your branch
being taken:

svn log svn+ssh://svn.kde.org/home/kde/trunk/KDE/kdemultimedia/kmix | less

Just look for the first revision prior to 1129222:

>From what I can gather it is:

r1128525 | esken | 2010-05-19 15:55:43 +0100 (Wed, 19 May 2010) | 3 lines

Fix menu bar hide problem.
BUGS: 191725


So we want to clone trunk at this state and then we'll pull in all the
subsequent changes:


[colin at jimmy kmix (master)]$ cd ..
[colin at jimmy christian]$ git svn clone -r 1128525
svn+ssh://svn.kde.org/home/kde/trunk/KDE/kdemultimedia/kmix kmix.trunk
[colin at jimmy kmix.trunk (master)]$ git svn rebase
	M	kmix.cpp
r1133816 = 030cef2692350120b5fddf4c0e46fc0d2717124d (refs/remotes/git-svn)
...
	M	Messages.sh
r1166369 = fe9e44e0bd2f186c059e8b1e2cfb29551bd90c1a (refs/remotes/git-svn)
First, rewinding head to replay your work on top of it...
Fast-forwarded master to refs/remotes/git-svn.
[colin at jimmy kmix.trunk (master)]$


OK, so you have "master" as your current state of trunk, but we still
need to incorporate your refactor work.

Firstly we'll create a branch in git for the refactor to live in. We'll
take this branch at the beginning (i.e. before trunk diverged).

[colin at jimmy kmix.trunk (master)]$ git checkout -b refactor beginning
Switched to a new branch 'refactor'

Now we can apply all your changes quite happily as we know that they
should all apply fine.

*********
Unfortunately this is where it all breaks.... The patches do not apply
fine at all.
*********

>From what I can gather, the branch you've been working on is actually
not a branch at all, but a totally new import of the kmix sources. And
that import appears to be divergent from the state of trunk at the time:
i.e. some changes were made prior to the initial commit!

We need to fix this...


In order to fix this we need to compare the changes between the two
repositories at the "beginning".

OK, so in order to do this:

[colin at jimmy kmix.trunk (master)]$ git checkout beginning
Note: checking out 'beginning'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at 4af0f54... Fix menu bar hide problem. BUGS: 191725
[colin at jimmy kmix.trunk ((beginning))]$ cd ../kmix/
[colin at jimmy kmix (master)]$ git checkout beginning
Note: checking out 'beginning'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at ca5aa67... KMix working branch
[colin at jimmy kmix (refactor)]$ cd ..
[colin at jimmy christian]$ diff -r --exclude .git kmix.trunk/ kmix/| less


And now we see all the differences in your initial branch than from trunk.

>From what I can tell you actually exported trunk, made some changes and
*then* committed the initial kmix working branch... in other words there
is a "lost" commit.

[colin at jimmy christian]$ diff -r --exclude .git kmix.trunk/ kmix/
>initial.changes.patch
[colin at jimmy christian]$ cd kmix.trunk/
[colin at jimmy kmix.trunk ((beginning))]$ git checkout refactor
[colin at jimmy kmix.trunk (refactor)]$ cat ../initial.changes.patch |
patch -p1
patching file CMakeLists.txt
patching file kmix.cpp
patching file mdwslider.cpp
patching file mdwslider.h
patching file mixer.cpp
patching file viewdockareapopup.cpp
patching file viewsliders.cpp
[colin at jimmy kmix.trunk (refactor)]$ git commit -am "kmix: Initial work
on refactor"
[refactor 338c8c0] kmix: Initial work on refactor
 7 files changed, 58 insertions(+), 10 deletions(-)


So, with that committed, all your patches should come in fine (make sure
to not include the initial.changes.patch again!):

[colin at jimmy kmix.trunk (refactor)]$ git am ../0*.patch
....
Applying: Bugfixes for hotplugging and closing tabs. CCBUGS: 209429
[colin at jimmy kmix.trunk (refactor)]$


Yay, we have a refactor based on trunk at the time you branched away.


Now we can rebase your refactor on trunk itself (which has a few more
commits now.

[colin at jimmy kmix.trunk (refactor)]$ git checkout -b refactor-trunk
Switched to a new branch 'refactor-trunk'
[colin at jimmy kmix.trunk (refactor-trunk)]$ git rebase master
.....

Applying: Add "Microphone" in the default configuration (ALSA backend)
Actually all controls macthcing "Mic.*" will be shown, as many
soundcards have a control that is labled "Mic".
Applying: Refactoring. GUIProfiles (for Tabs) work better now. Still a
lot of work. CCBUGS: 209429
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging kmix.cpp
CONFLICT (content): Merge conflict in kmix.cpp
Failed to merge in the changes.
Patch failed at 0011 Refactoring. GUIProfiles (for Tabs) work better
now. Still a lot of work. CCBUGS: 209429

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".

[colin at jimmy kmix.trunk ((afb7912...)|REBASE)]$

OK, so that patch failed to be incorporated in the rebase. Let's fix it.

[colin at jimmy kmix.trunk ((afb7912...)|REBASE)]$ git st
# Not currently on any branch.
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	modified:   guiprofile.cpp
#	modified:   guiprofile.h
#	modified:   kmixerwidget.cpp
#	modified:   kmixerwidget.h
#	modified:   mixer.cpp
#	modified:   mixer.h
#	modified:   mixertoolbox.cpp
#	modified:   mixertoolbox.h
#
# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#	both modified:      kmix.cpp
#


<edit kmix.cpp and resolve conflicts>

Turns out patch 0010 contained a lot of whitespace changes (whitespace
changes are evil!) and that's why it failed to apply. Manual resolution
is the only way.

BIG NOTE: You should probably try to stick to your whitespace changes
(i.e. redo them, don't remove them). This is because the next patches to
be rebased will be of course based on your whitespace changes.

You should in theory be able to do a compile test here...

Once you are happy with your changes:

[colin at jimmy kmix.trunk ((afb7912...)|REBASE)]$ git add kmix.cpp
[colin at jimmy kmix.trunk ((afb7912...)|REBASE)]$ git status
# Not currently on any branch.
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	modified:   guiprofile.cpp
#	modified:   guiprofile.h
#	modified:   kmix.cpp
#	modified:   kmixerwidget.cpp
#	modified:   kmixerwidget.h
#	modified:   mixer.cpp
#	modified:   mixer.h
#	modified:   mixertoolbox.cpp
#	modified:   mixertoolbox.h
#
[colin at jimmy kmix.trunk ((afb7912...)|REBASE)]$ git rebase --continue
Applying: Refactoring. GUIProfiles (for Tabs) work better now. Still a
lot of work. CCBUGS: 209429
Applying: Implement saving of Subcontrol information to profile
...

And it breaks again.

Edit file, and repeat.


Once you are done, you should be left wiht a branch called
"refactor-trunk" in git. THis should be all your refactored stuff, with
trunk changes all combined.

You can do e.g.

"git shortlog master..refactor-trunk" to see a summary of your changes.

You can do a git log and look at the individual commits etc.

Once you are truely happy with everything do:

git checkout master
git rebase master-trunk (this will fast-forward, so it's the same as a
merge)

Then you can do:

git svn rebase (just to pull in any changes in trunk since doing this
whole thing).

And finally:

git svn dcommit.


Phew!!!


Hope that helps!


Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]