RE: The idea isn't clear...

[Matthew Herrmann]

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:address@hidden
Sent: Tuesday, 3 June 2003 22:46
To: address@hidden
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" <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
>