[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: New KMix version about to be checked in - a complete replacement
From:       Colin Guthrie <gmane () colin ! guthr ! ie>
Date:       2010-08-23 9:55:23
Message-ID: i4tgib$bu6$1 () dough ! gmane ! org
[Download RAW message or body]

'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, doing git format-patch, creating a new git-svn from trunk and
then git am'ing all the patches, fixing any (likely minor) conflicts
that result and then dcommitting the result to svn trunk.

It's a bit of effort to go to but it's not super hard. I'd be willing to
try and do it on your behalf if you like. I can then push the git tree
out or give you exact instructions on how to commit the end result, so
that authorship is properly maintained.



Either that or just issue a single svn merge and commit the results. It
really depends how others want it to work as I don't really have much
sway in this.

Obviously the full solution of "change everything to git" is not going
to work in the timescales :D

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/]

_______________________________________________
kde-multimedia mailing list
kde-multimedia@kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia


[prev in list] [next in list] [prev in thread] [next in thread]