Re: The idea isn't clear...

[Matthew Herrmann]

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" <address@hidden>
> To: <address@hidden>
> Cc: <address@hidden>
> 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" <address@hidden>
>> To: <address@hidden>
>> Subject: Re: The idea isn't clear...
>> Message-ID: <address@hidden>
>> References:
>>
>>
> <address@hidden><000d01c32561$8
>> address@hidden>
>> <address@hidden>
>> 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