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
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
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...
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 AT&T '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...
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