<div dir="ltr">Hi there<div><br></div><div><br></div><div>I think this is very reasonable. </div><div>branches/plasma5 has been apart for a long time...</div><div>So please go for it.</div><div><br></div><div><br></div><div>mfg Tobias</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 13 July 2016 at 18:17, Adriaan de Groot <span dir="ltr"><<a href="mailto:groot@kde.org" target="_blank">groot@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We have been developing KDE-FreeBSD packages in area51 for a long time (since<br>
2003!). And recently, we've had a very long-lived branch, namely plasma5, in<br>
parallel with trunk. The differences between plasma5 and trunk are roughly<br>
these:<br>
<br>
- trunk has qt 5.6, plasma5 5.5 (and right now, plasma5 requires qt 5.6)<br>
- plasma5 has kf5, plasma5, newer applications<br>
- along the road to plasma5, there was a huge amount of renaming and shuffling<br>
of ports<br>
- there have been some merges from trunk -> plasma5<br>
- there have been merges from official ports -> trunk (sometimes -> plasma5)<br>
- there have been a few single commits merged plasma5->trunk<br>
<br>
<br>
I've spent a bunch of time trying to merge plasma5 to trunk with svn merge<br>
(e.g. svn merge -r 10672:HEAD ../plasma5 . when in a trunk-checkout). This is,<br>
to be frank, a pain in the butt. SVN is just not that good with horribly<br>
confused history.<br>
<br>
So I'd like to propose: "never mind" wrt. actually merging history to trunk.<br>
<br>
This wouldn't be the first time such a thing has been done in area51. And it's<br>
not like history would go away, it just wouldn't be obvious from looking at<br>
just the log of trunk.<br>
<br>
The difference between doing an svn merge and "nevery mind" is this: "never<br>
mind" takes about 10 minutes to do (technically) and then I can start building<br>
the port x11/kde5 in trunk against the qt 5.6 which is in trunk. Merging SVN<br>
history 10672-11503 (which is the first time SVN just gives up and dumps you<br>
out to a situation with 300 text conflicts and 40-odd tree conflicts) takes<br>
hours or days of editing individual files and tracking history to decide which<br>
bits go where and whether plasma5, workdir, or history is the right thing to<br>
keep (and then once that's done, doing it again and again until plasma5 is<br>
fully merged).<br>
<br>
Frankly, I can't be bothered.<br>
<br>
So here's my "never mind" plan:<br>
<br>
# Just throw everything out<br>
cd trunk<br>
rm -rf $(find . -name Makefile | xargs dirname)<br>
# Copy plasma5's structure back<br>
cd ../plasma5<br>
tar cf - --exclude .svn . | tar xf - -C ../trunk<br>
# .. except Qt5 is newer in trunk<br>
svn revert -R QT<br>
rm -rf $(svn st QT | grep '^?' | cut -w -f 1)<br>
<br>
There may be a little bit of stuff to sort out after that (just in terms of<br>
what ports to add / delete from the other sub-dirs), but it's quick, it bumps<br>
trunk to the next set of things-we-want-to-flush-downstream and gets things<br>
moving again instead of stuck with trunk (awaiting nothing), plasma5 (awaiting<br>
a Qt refresh) and qt-5.7 (early stages, and languishing wrt plasma5 and ports<br>
updates).<br>
<br>
So, yeah, let's trade easy-to-follow history for getting-things-done.<br>
<br>
Comments? Suggestions? I'd like to replace trunk with something fresh friday<br>
at the latest, if noone objects.<br>
<br>
[ade]<br>
_______________________________________________<br>
kde-freebsd mailing list<br>
<a href="mailto:kde-freebsd@kde.org">kde-freebsd@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-freebsd" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/kde-freebsd</a><br>
See also <a href="http://freebsd.kde.org/" rel="noreferrer" target="_blank">http://freebsd.kde.org/</a> for latest information<br>
</blockquote></div><br></div>