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