[gnugo-devel] cvs update difficulties.

[Trevor Morris]

Dan said:
>Trevor said:
>> The clashes I have a problem with are mostly with my own code.
>> Perhaps I'm missing something in the way I use CVS.  If I make
>> changes to code that's not been accepted yet, when I do
>> finally "cvs update", I almost always get clashes.  So I
>> tend to avoid doing anything until my patch has been accepted,
>> then I update and continue.
>> 
>> Here's an example from today's update:
>> 
>> C engine/board.c
>> C engine/reading.c
>> C patterns/mkpat.c
>> C patterns/patterns.h
>> 
>> Here's the diff to patterns.h:
>> Upon close inspection, you can see that I've just added a comment
>> line reminding myself to move a struct out of the header file to
>> the c file.  However, that caused a lot of conflict.
>
>This shouldn't happen.
>
>The only time when you should get clashes is when someone
>else is working on the same lines of the same file. If you
>CVS checkout a version after you've made some changes,
>you should get 
>
>M [filename]
>
>If your working copy contains changes that have already
>been checked in you'll get an additional message to the
>effect that your file already contains the changes.
>
>I notice in the example that the lines which CVS claims
>are different look the same and I wonder if they differ
>in whitespace. Occasionally your patches come with ^M's
>in them in places where you didn't seem to modify
>anything and I wonder if your editor has been adding
>extraneous carriage rerturn.
Yes, my editor does this heanous thing to me.  This patch
did have some ^M's in it, but not in all the files that
had clashes.

>This could explain the clashes. I just looked in the
>CVS doc to see if CVS update had any provision for
>ignoring whitespace and I didn't find anything.
Yes, funny thing is that cvs diff does have this option.

>I think we should take this to the list. Teun is back
>and he or David might think of something. If you want
>to revise this for the list you could quote my
>comments or else I can post them after the message
>appears.

I do often see M [filename] during an update, and often it
works without a problem.

What happened, step by step:

1) I submitted trevor_1_27.7
2) I continued working on my source tree that had these changes
   in it already.
3) Dan added trevor_1_27.7 to CVS.
4) I ran CVS update.
5) I got large merge conflicts in the files I'd modified.

Below is a longish example from pattern.h.  The only thing that
I'd changed was to add a two line comment in the middle of a
long block of new text.  Rather than marking just those two
lines as a conflict, it marked the whole section.  Here it's
not so bad, but in mkpat.c there were some very long sections
with the same problem.  Am I doing something wrong?


<<<<<<< patterns.h

/* Tree-based pattern matching structures*/
/* FIXME: graph_* should be renamed to tree_* */

struct match_node;
struct graph_node_list;

struct match_node {
  int patnum;
  int orientation;
  struct match_node *next;
};


struct graph_node {
  struct match_node *matches;
  int att;
  int x;
  int y;
  struct graph_node_list *next_list;
};

struct graph_node_list {
  struct graph_node node;
  struct graph_node_list *next;
};


/* FIXME: This needn't be defined in the header file. */
struct element_node {
  struct patval e;
  struct element_node *next;
};


=======

/* Tree-based pattern matching structures*/
/* FIXME: graph_* should be renamed to tree_* */

struct match_node;
struct graph_node_list;

struct match_node {
  int patnum;
  int orientation;
  struct match_node *next;
};


struct graph_node {
  struct match_node *matches;
  int att;
  int x;
  int y;
  struct graph_node_list *next_list;
};

struct graph_node_list {
  struct graph_node node;
  struct graph_node_list *next;
};


struct element_node {
  struct patval e;
  struct element_node *next;
};


>>>>>>> 1.23