Re: The idea isn't clear...
Hi Matthew, I agree with you. That's why we've decided to use CVS. Besides those conflicts problems, we have a gain in productivity since we do not have to wait for a developer to stop editing a file. Unfortunately, the CVS Eclipse plugin does not shows if someone is editing a file, what has made us synchronize all the time. Regards, Giovanni Giazzon - Original Message - From: Matthew Herrmann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 5:03 AM Subject: Re: The idea isn't clear... Hi Giovanni, The only way to prevent these conflicts is to organise from a ppl management perspective which developers are working on which files. If people work in a source-safe way on separate files (which happens most of the time), then people will not get any conflicts at all when they synchronize. If they get a lot of conflicts, then they would have been spending a lot of time waiting for each other to unlock the file so they could change one line, then give it back to the other guy so he adds one line etc. Essentially in both systems, it is a pain for 2 people to be working on the same part of the document : either because it is locked most of the time, or because of conflicts after finishing work. I like the commit merge model, because it allows users to make innocuous changes like changing visibility of classes others are working on without needing a file lock. HTH, Matthew Giovanni Giazzon said: Yes, it has this option and it is helpful. But, it has to be called by the developers so, again, bad things can happen when editing the same file. Even though, we do this synchronization before edit and before commit. I think that there is no way to prevent these conflicts in concurrent implementation. It is something that I'm not used to, since I'm coming from SourceSafe-like version control systems. Thanks, Giovanni Giazzon - Original Message - From: Matthew Herrmann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, June 02, 2003 2:12 AM Subject: Re: The idea isn't clear... Eclipse goes one further and gives you an opportunity to synchronise in a clean area, where you can review changes that come in before they are automatically merged. This is better than vanilla CVS, though it is a bit slower to handle over dial-up. It should be called synchronize with repository option (or something similar). Essentially, each user does not need to worry about the other until they commit. The bigger the change, the more likely the last person to commit will need to resolve conflicts with other users. -Original Message- Date: Thu, 29 May 2003 14:54:40 -0300 From: Giovanni Giazzon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: The idea isn't clear... Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED]000d01c32561$8 [EMAIL PROTECTED] [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: list Message: 1 you'll get a warning about being not up to date That would be great, but I'm working with CVS and Eclipse and that warning does not seems to exist (it's a plugin to connect to a CVS server). I did some tests here with one branch being shared between two developers, and without that warning things can get dangerous. But this approach looks better than the a branch per developer one. Does anybody have experience with CVS and Eclipse in this list? Thanks, Giovanni Giazzon ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: The idea isn't clear...
I think this problem is endemic to the whole checkout-merge-commit model. Nor Eclipse nor any other tool will be able to handle this in CVS, although maybe it could send CVS users notifications of commits, and automatically run cvs up if it was guaranteed to generate no conflicts. There's a hook for this actually, so it could be done. That would actually be quite a safe and useful tool, methinks -- providing you could run hook scripts as part of the client to run your build scripts. -Original Message- From: Giovanni Giazzon [mailto:[EMAIL PROTECTED] Sent: Tuesday, 3 June 2003 22:46 To: [EMAIL PROTECTED] Cc: Matthew Herrmann Subject: Re: The idea isn't clear... Hi Matthew, I agree with you. That's why we've decided to use CVS. Besides those conflicts problems, we have a gain in productivity since we do not have to wait for a developer to stop editing a file. Unfortunately, the CVS Eclipse plugin does not shows if someone is editing a file, what has made us synchronize all the time. Regards, Giovanni Giazzon - Original Message - From: Matthew Herrmann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 5:03 AM Subject: Re: The idea isn't clear... Hi Giovanni, The only way to prevent these conflicts is to organise from a ppl management perspective which developers are working on which files. If people work in a source-safe way on separate files (which happens most of the time), then people will not get any conflicts at all when they synchronize. If they get a lot of conflicts, then they would have been spending a lot of time waiting for each other to unlock the file so they could change one line, then give it back to the other guy so he adds one line etc. Essentially in both systems, it is a pain for 2 people to be working on the same part of the document : either because it is locked most of the time, or because of conflicts after finishing work. I like the commit merge model, because it allows users to make innocuous changes like changing visibility of classes others are working on without needing a file lock. HTH, Matthew Giovanni Giazzon said: Yes, it has this option and it is helpful. But, it has to be called by the developers so, again, bad things can happen when editing the same file. Even though, we do this synchronization before edit and before commit. I think that there is no way to prevent these conflicts in concurrent implementation. It is something that I'm not used to, since I'm coming from SourceSafe-like version control systems. Thanks, Giovanni Giazzon - Original Message - From: Matthew Herrmann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, June 02, 2003 2:12 AM Subject: Re: The idea isn't clear... Eclipse goes one further and gives you an opportunity to synchronise in a clean area, where you can review changes that come in before they are automatically merged. This is better than vanilla CVS, though it is a bit slower to handle over dial-up. It should be called synchronize with repository option (or something similar). Essentially, each user does not need to worry about the other until they commit. The bigger the change, the more likely the last person to commit will need to resolve conflicts with other users. -Original Message- Date: Thu, 29 May 2003 14:54:40 -0300 From: Giovanni Giazzon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: The idea isn't clear... Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED]000d01c32561$8 [EMAIL PROTECTED] [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: list Message: 1 you'll get a warning about being not up to date That would be great, but I'm working with CVS and Eclipse and that warning does not seems to exist (it's a plugin to connect to a CVS server). I did some tests here with one branch being shared between two developers, and without that warning things can get dangerous. But this approach looks better than the a branch per developer one. Does anybody have experience with CVS and Eclipse in this list? Thanks, Giovanni Giazzon ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: The idea isn't clear...
Yes, it has this option and it is helpful. But, it has to be called by the developers so, again, bad things can happen when editing the same file. Even though, we do this synchronization before edit and before commit. I think that there is no way to prevent these conflicts in concurrent implementation. It is something that I'm not used to, since I'm coming from SourceSafe-like version control systems. Thanks, Giovanni Giazzon - Original Message - From: Matthew Herrmann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, June 02, 2003 2:12 AM Subject: Re: The idea isn't clear... Eclipse goes one further and gives you an opportunity to synchronise in a clean area, where you can review changes that come in before they are automatically merged. This is better than vanilla CVS, though it is a bit slower to handle over dial-up. It should be called synchronize with repository option (or something similar). Essentially, each user does not need to worry about the other until they commit. The bigger the change, the more likely the last person to commit will need to resolve conflicts with other users. -Original Message- Date: Thu, 29 May 2003 14:54:40 -0300 From: Giovanni Giazzon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: The idea isn't clear... Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED]000d01c32561$8 [EMAIL PROTECTED] [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: list Message: 1 you'll get a warning about being not up to date That would be great, but I'm working with CVS and Eclipse and that warning does not seems to exist (it's a plugin to connect to a CVS server). I did some tests here with one branch being shared between two developers, and without that warning things can get dangerous. But this approach looks better than the a branch per developer one. Does anybody have experience with CVS and Eclipse in this list? Thanks, Giovanni Giazzon ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: The idea isn't clear...
[ On Friday, May 30, 2003 at 12:36:21 (-0400), Eric Siegerman wrote: ] Subject: Re: The idea isn't clear... I suspect that the above diff hunk is an unrelated change. It seems unrelated to the conflict-marking style. Yes, actually it is -- the stat() is there so that one more un-related change hunk, that I did manage to delete, can work, which is the one that chmod's the merged file's mode bits back to match the original. I used to make this change too (well, the s/-E/-A/ part; the -T is orthogonal), but recently discovered a drawback -- for me, Yes, '-T' is sort of orthogonal, though I've found it's another critical part of making the conflict markers more easily read and understood. (note that in theory the '-A' is not necessary since it is the default with '-m', but I like to be explicit about these things, especially in places where I need to remember what was intended) The problem is that the s/-E/-A/ patch breaks this detection, and instead of a nice message, you get spurious merge conflicts. Well I don't find that to be a show-stopper (far from it), though it is sad that diff3 does fail to detect this often useful bit of information about conflicts when '-A' is used. The real problem I have is that often the spurious conflicts are not marked properly -- i.e. in the desired full '-A' form. I find the '-A' form far more critical for daily use than the occasional spurious or poorly marked conflict. I think the problem is in diff3. -A does two things: 1. makes diff3 dumber about identifying conflicts (suppresses the intelligence that would have suppressed the conflict in the above case) Although the documentation alludes to this I'm not sure it's the full intention -- just a side-effect. :-) I've found the diff3 options to be _extremely_ poorly documented, often to the extent that the docs seem to disagree with the code. The code is extremely over-complicated too, with several cases of using multiple separate variables to control what should be binary flags, while at other times using multi-state variables to control what should be separate binary flags. Coincidentally I had a very similarj discussion with Larry McVoy when he was working on the merge tool for BitKeeper. :-) 2. once a conflict has been identified, displays its ancestor version as well as the two child versions Of course, (2) is what we're after, but diff3 provides no way to get that without also getting (1). Perhaps we should file a bug report with the GNU diff maintainers I'm betting these are perfect examples of bugs caused by programmers who are (or at least think they are) just too familiar with their own code and who don't bother to test usages they don't use themselves. Of course there's one other obvious solution to this problem and that's to use 'patch' instead of 'diff3' for merging, and whenever 'diff3' fails me that's often what I do (and other times I use Emacs Ediff). It would be nice if 'patch' would annotate the *.rej file with comments about why the change was rejected of course (such as when a specific chagne is already present), but that's a relatively minor thing and should be easy enough to fix since it's more or less already spewing this information on its stdout. FYI, last I heard from Larry was that he was going to stop using 'diff3' and instead just do run two separate ordinary 'diff' processes and then do the merging and conflict detection of their output using his own code. This is of course something like what the original ATT 'diff3' implementation did (leaving out the obvious error handling): case $1 in -[ex3]) flg=$1 shift;; esac mine=$1 ancestor=$2 yours=$3 diff $mine $yours /tmp/d3a$$ diff $ancestor $yours /tmp/d3b$$ /usr/lib/diff3prog $flg /tmp/d3[ab]$$ $mine $ancestor $yours What CVS really needs to do is take all the changes from DELTA($ancestor to $yours) and merge them into $mine, marking any conflicts where changes from DELTA($ancestor to $mine) would conflict with the first set of changes, and ignoring, perhaps verbosely, changes in DELTA($ancestor to $yours) which are already present in DELTA($ancestor to $mine). As far as I can tell no current variant of 'diff3' implements exactly this procedure in any way shape or form. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: The idea isn't clear...
Hi Giovanni, The only way to prevent these conflicts is to organise from a ppl management perspective which developers are working on which files. If people work in a source-safe way on separate files (which happens most of the time), then people will not get any conflicts at all when they synchronize. If they get a lot of conflicts, then they would have been spending a lot of time waiting for each other to unlock the file so they could change one line, then give it back to the other guy so he adds one line etc. Essentially in both systems, it is a pain for 2 people to be working on the same part of the document : either because it is locked most of the time, or because of conflicts after finishing work. I like the commit merge model, because it allows users to make innocuous changes like changing visibility of classes others are working on without needing a file lock. HTH, Matthew Giovanni Giazzon said: Yes, it has this option and it is helpful. But, it has to be called by the developers so, again, bad things can happen when editing the same file. Even though, we do this synchronization before edit and before commit. I think that there is no way to prevent these conflicts in concurrent implementation. It is something that I'm not used to, since I'm coming from SourceSafe-like version control systems. Thanks, Giovanni Giazzon - Original Message - From: Matthew Herrmann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, June 02, 2003 2:12 AM Subject: Re: The idea isn't clear... Eclipse goes one further and gives you an opportunity to synchronise in a clean area, where you can review changes that come in before they are automatically merged. This is better than vanilla CVS, though it is a bit slower to handle over dial-up. It should be called synchronize with repository option (or something similar). Essentially, each user does not need to worry about the other until they commit. The bigger the change, the more likely the last person to commit will need to resolve conflicts with other users. -Original Message- Date: Thu, 29 May 2003 14:54:40 -0300 From: Giovanni Giazzon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: The idea isn't clear... Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED]000d01c32561$8 [EMAIL PROTECTED] [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: list Message: 1 you'll get a warning about being not up to date That would be great, but I'm working with CVS and Eclipse and that warning does not seems to exist (it's a plugin to connect to a CVS server). I did some tests here with one branch being shared between two developers, and without that warning things can get dangerous. But this approach looks better than the a branch per developer one. Does anybody have experience with CVS and Eclipse in this list? Thanks, Giovanni Giazzon ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: The idea isn't clear...
Eclipse goes one further and gives you an opportunity to synchronise in a clean area, where you can review changes that come in before they are automatically merged. This is better than vanilla CVS, though it is a bit slower to handle over dial-up. It should be called synchronize with repository option (or something similar). Essentially, each user does not need to worry about the other until they commit. The bigger the change, the more likely the last person to commit will need to resolve conflicts with other users. -Original Message- Date: Thu, 29 May 2003 14:54:40 -0300 From: Giovanni Giazzon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: The idea isn't clear... Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED]000d01c32561$8 [EMAIL PROTECTED] [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: list Message: 1 you'll get a warning about being not up to date That would be great, but I'm working with CVS and Eclipse and that warning does not seems to exist (it's a plugin to connect to a CVS server). I did some tests here with one branch being shared between two developers, and without that warning things can get dangerous. But this approach looks better than the a branch per developer one. Does anybody have experience with CVS and Eclipse in this list? Thanks, Giovanni Giazzon ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: The idea isn't clear...
On Wed, May 28, 2003 at 07:29:58PM -0400, Greg A. Woods wrote:
[ On Wednesday, May 28, 2003 at 15:24:09 (-0700), Jim wrote: ]
stuff
===
other stuff
It's one hell of a lot easier to tell what's going on with conflicts if
you fix CVS to call diff3 in such a way that it includes the full
conflict information:
[reluctantly quoting almost the entire patch, since I don't see
how to edit it down...]
$ cvs diff rcscmds.c
[...]
***
*** 245,254
--- 245,258
char *tmp1, *tmp2;
char *diffout = NULL;
int retval;
+ struct stat file_info;
if (options != NULL options[0] != '\0')
assert (options[0] == '-' options[1] == 'k');
+ if (CVS_STAT (workfile, file_info) 0)
+ error (1, errno, could not stat %s, workfile);
+
cvs_output (RCS file: , 0);
cvs_output (rcs-path, 0);
cvs_output (\n, 1);
I suspect that the above diff hunk is an unrelated change. It
seems unrelated to the conflict-marking style.
***
*** 298,305
only for diagnostic messages -- CVS no longer forks to run diff3. */
diffout = cvs_temp_name();
call_diff_setup (diff3);
! call_diff_arg (-E);
! call_diff_arg (-am);
call_diff_arg (-L);
call_diff_arg (workfile);
--- 302,308
only for diagnostic messages -- CVS no longer forks to run diff3. */
diffout = cvs_temp_name();
call_diff_setup (diff3);
! call_diff_arg (-ATam);
call_diff_arg (-L);
call_diff_arg (workfile);
I used to make this change too (well, the s/-E/-A/ part; the -T
is orthogonal), but recently discovered a drawback -- for me,
it's a showstopper; I've had to revert the change.
Suppose you make a local change to a third-party package (I use
the vendor branch, but I strongly doubt that's relevent). You
submit your change, and it's incorporated without modification
into the canonical source. When you merge after importing the
new version, CVS decides that what looked at first like a
conflict, really isn't, because the conflicting change is
identical in both child versions. CVS just accepts the change,
and prints this message:
${file} already contains the differences between ${rev1} and ${rev2}
The problem is that the s/-E/-A/ patch breaks this detection, and
instead of a nice message, you get spurious merge conflicts.
I think the problem is in diff3. -A does two things:
1. makes diff3 dumber about identifying conflicts (suppresses
the intelligence that would have suppressed the conflict in
the above case)
2. once a conflict has been identified, displays its ancestor
version as well as the two child versions
Of course, (2) is what we're after, but diff3 provides no way to
get that without also getting (1).
--
| | /\
|-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
When I came back around from the dark side, there in front of me would
be the landing area where the crew was, and the Earth, all in the view
of my window. I couldn't help but think that there in front of me was
all of humanity, except me.
- Michael Collins, Apollo 11 Command Module Pilot
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: The idea isn't clear...
you'll get a warning about being not up to date That would be great, but I'm working with CVS and Eclipse and that warning does not seems to exist (it's a plugin to connect to a CVS server). I did some tests here with one branch being shared between two developers, and without that warning things can get dangerous. But this approach looks better than the a branch per developer one. Does anybody have experience with CVS and Eclipse in this list? Thanks, Giovanni Giazzon - Original Message - From: Jim [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 28, 2003 7:24 PM Subject: Re: The idea isn't clear... demand, you might have logical concurrence in different implementations. But, is this right? That's the way to work with CVS? No - actually everyone works on the same branch(trunk)(path?), occasionally when you go to commit there could be times where someone else has already commited changes, you'll get a warning about being not up to date, but then do an update, and cvs'll merge the changes in with the current changes (and if there's conflicts whcih get marked with stuff === other stuff though I'm not sure whether the top or the bottom is more recent... it's ususally easy to tell which is the correct one... branches are more for after having released a version, and after continued development, you have to go back to the release point and make mods... then bring that small branch back into the main tree Regards, Giovanni Giazzon ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
The idea isn't clear...
Hi all, I'm quite new to CVS, and I'm having some difficulties to understand it's logic. I have a project in the HEAD section, and I've created a branch to each developer. So they work on it, commit on it, and we are all happy, but when comes the time to generate a new version and merge each branch, I feel like having no gain in productivity. It's hard to merge three or more branches since different implementations can converge in a same file. That's the problem of work with multiple instances of a same file: if you work by demand, you might have logical concurrence in different implementations. But, is this right? That's the way to work with CVS? Regards, Giovanni Giazzon ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: The idea isn't clear...
Why does each developer need his or her own branch. Just pull a workspace and have the developer treat his local workspace as a branch. That way whoever commits first forces everyone else to auto-update and pull in the changes... Instead of waiting till the end. donald On Wed, May 28, 2003 at 06:39:00PM -0300, Giovanni Giazzon wrote: Hi all, I'm quite new to CVS, and I'm having some difficulties to understand it's logic. I have a project in the HEAD section, and I've created a branch to each developer. So they work on it, commit on it, and we are all happy, but when comes the time to generate a new version and merge each branch, I feel like having no gain in productivity. It's hard to merge three or more branches since different implementations can converge in a same file. That's the problem of work with multiple instances of a same file: if you work by demand, you might have logical concurrence in different implementations. But, is this right? That's the way to work with CVS? Regards, Giovanni Giazzon ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: The idea isn't clear...
demand, you might have logical concurrence in different implementations. But, is this right? That's the way to work with CVS? No - actually everyone works on the same branch(trunk)(path?), occasionally when you go to commit there could be times where someone else has already commited changes, you'll get a warning about being not up to date, but then do an update, and cvs'll merge the changes in with the current changes (and if there's conflicts whcih get marked with stuff === other stuff though I'm not sure whether the top or the bottom is more recent... it's ususally easy to tell which is the correct one... branches are more for after having released a version, and after continued development, you have to go back to the release point and make mods... then bring that small branch back into the main tree Regards, Giovanni Giazzon ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: The idea isn't clear...
[ On Wednesday, May 28, 2003 at 15:24:09 (-0700), Jim wrote: ] Subject: Re: The idea isn't clear... stuff === other stuff though I'm not sure whether the top or the bottom is more recent... it's ususally easy to tell which is the correct one... It's one hell of a lot easier to tell what's going on with conflicts if you fix CVS to call diff3 in such a way that it includes the full conflict information: $ cvs diff rcscmds.c Index: rcscmds.c === RCS file: /home2/cvsroot/ccvs/src/rcscmds.c,v retrieving revision 1.50 diff -c -r1.50 rcscmds.c *** rcscmds.c 14 Feb 2001 04:31:27 - 1.50 --- rcscmds.c 28 May 2003 23:27:09 - *** *** 245,254 --- 245,258 char *tmp1, *tmp2; char *diffout = NULL; int retval; + struct stat file_info; if (options != NULL options[0] != '\0') assert (options[0] == '-' options[1] == 'k'); + if (CVS_STAT (workfile, file_info) 0) + error (1, errno, could not stat %s, workfile); + cvs_output (RCS file: , 0); cvs_output (rcs-path, 0); cvs_output (\n, 1); *** *** 298,305 only for diagnostic messages -- CVS no longer forks to run diff3. */ diffout = cvs_temp_name(); call_diff_setup (diff3); ! call_diff_arg (-E); ! call_diff_arg (-am); call_diff_arg (-L); call_diff_arg (workfile); --- 302,308 only for diagnostic messages -- CVS no longer forks to run diff3. */ diffout = cvs_temp_name(); call_diff_setup (diff3); ! call_diff_arg (-ATam); call_diff_arg (-L); call_diff_arg (workfile); This should have been changed years ago. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: The idea isn't clear...
--- Forwarded mail from [EMAIL PROTECTED] It's one hell of a lot easier to tell what's going on with conflicts if you fix CVS to call diff3 in such a way that it includes the full conflict information: [context diff omitted] This should have been changed years ago. --- End of forwarded message from [EMAIL PROTECTED] Whoa! Greg wants a change to CVS? Everybody hold on while the world stops spinning! :-) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
