[RFC] Workingstyle of different VCS systems

[Andreas Pakulat]

On 10.04.07 17:57:10, Matthew Woehlke wrote:
> Andreas Pakulat wrote:
> > On 10.04.07 09:39:58, Matthew Woehlke wrote:
> >> What happens in svn when a merge fails?
> > 
> > You get a file wich is in a conflict state and cannot be committed as it
> > is (until you do svn resolved). [snip]
> 
> I meant when the attempt to patch *fails*, i.e. cannot determine what to 
> patch (e.g. because I did something stupid like 'merge foo.c#4 foo.c#5 
> bar.c'). Although I imagine perforce would choke similarly. Mainly I'm 
> just curious. :-)

This doesn't fail. It just generates a hell of a lot of conflicts. Like
this:
andreas at morpheus:~/KDE-work/4.0/kdevelop/buildtools/builders/qmakebuilder>svn merge https://svn.kde.org/home/kde/trunk/KDE/kdevelop/buildtools/managers/cmake/cmakepreferences.cpp@648393 https://svn.kde.org/home/kde/trunk/KDE/kdevelop/buildtools/managers/cmake/cmakepreferences.cpp@648395 qmakebuilderconfig.kcfg
C    qmakebuilderconfig.kcfg
andreas at morpheus:~/KDE-work/4.0/kdevelop/buildtools/builders/qmakebuilder>svn diff qmakebuilderconfig.kcfg
Index: qmakebuilderconfig.kcfg
===================================================================
--- qmakebuilderconfig.kcfg     (Revision 652200)
+++ qmakebuilderconfig.kcfg     (Arbeitskopie)
@@ -1,3 +1,4 @@
+<<<<<<< .working
 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE kcfg SYSTEM "http://www.kde.org/standards/kcfg/1.0/kcfg.dtd">
 <kcfg>
@@ -6,3 +7,61 @@
          <entry name="qmakebin" key="QMake Binary" type="Url" />
   </group>
 </kcfg>
+=======
+/* KDevelop CMake Support
+ *
+ * Copyright 2006 Matt Rogers <mattr at kde.org>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ */
+
+#include "cmakepreferences.h"
+
+#include <vector>
+
+#include <QVBoxLayout>
+
+#include <kurl.h>
+#include <kgenericfactory.h>
+
+#include "ui_cmakebuildsettings.h"
+#include "cmakeconfig.h"
+
+typedef KGenericFactory<CMakePreferences> CMakePreferencesFactory;
+K_EXPORT_COMPONENT_FACTORY( kcm_kdevcmake_settings, CMakePreferencesFactory( "kcm_kdevcmake_settings" )  )
+
+CMakePreferences::CMakePreferences(QWidget* parent, const QStringList& args)
+    : ProjectKCModule<CMakeSettings>(CMakePreferencesFactory::componentData(), parent, args)
+{
+    QVBoxLayout* l = new QVBoxLayout( this );
+    QWidget* w = new QWidget;
+    m_prefsUi = new Ui::CMakeBuildSettings;
+    m_prefsUi->setupUi( w );
+    l->addWidget( w );
+
+    addConfig( CMakeSettings::self(), w );
+
+    load();
+
+}
+
+CMakePreferences::~CMakePreferences()
+{
+}
+
+
+//kate: space-indent on; indent-width 4; replace-tabs on;
+>>>>>>> .merge-rechts.r648395


> >> Well, perforce doesn't *require* you to do the resolve right away, but I 
> >> can't think of any use case where you would want to do something after 
> >> the integrate but before the resolve.
> > 
> > Hmm, given that we will have "resolve" action anyway (as conflicts in
> > svn can happen on normal updates), I guess we can as well let the merge
> > be without the resolve. The backend can then update the state properly,
> > i.e. in perforce all files are marked as conflict or "needs resolve" and
> > the user can then select all files or specific ones to resolve...
> 
> The only reason I'm worried about that is it prevents an automated 
> merge() because user intervention will *always* be required. Maybe 
> merge() should take some QFlags, one of which says we should force an 
> attempt to do automatic merges (this would be default)? Hmm, but then 
> how to implement that in a shared UI?

Well, perforce could do the merge automatically and it would fail on any
files that need user interaction to merge properly (due to conflicts).
Then it would pretty much resemble svn behaviour, where the merge would
be done implictly by svn.

Andreas

-- 
Tomorrow will be cancelled due to lack of interest.