info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The idea isn't clear...


From: Giovanni Giazzon
Subject: Re: The idea isn't clear...
Date: Tue, 3 Jun 2003 09:46:10 -0300

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" <address@hidden>
To: <address@hidden>
Cc: <address@hidden>
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" <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
>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]