Re: "Concurrent" VS...

[Noel L Yap]

I had thought (based on some ACM article I had read) of making something like
this almost ten years ago.  It's a great academic excercise.

The problem with concurrent editing (at least for software development) is that
things would probably never build since, at any given time, a file being edited
by multiple people will always have syntax errors (well, maybe I'm exagerating
but I think the point is clear).  Now, for things that don't have a short cycle
(eg edit, build) like documentation, this may work.

Noel




address@hidden on 2001.03.01 12:00:11
A thought :


    This discussion got me thinking |-T. On www.xemacs.org, there's an emacs
package called egret.  From what I understand, it's part of a network file
sharing system that lets people edit the same file simultaneously, seeing
all other changes made by anyone else in real-time.  I have not used it (I
couldn't get the server to compile :-( ), but it sounds exciting. While
probably not (yet) feasible over the internet, for users working in a fast
intranet or on the same machine it seems possible that this could eliminate
many merge/conflict problems, and would certainly foster developer
communication--editing source code could be a direct form of communication
itself!  Perhaps this is the future for concurrent development. (?)

    Can anyone relate anything about using this for concurrent development
with CVS?

Tim S.

----- Original Message -----
From: "Noel L Yap" <address@hidden>
To: <address@hidden>
Cc: <address@hidden>
Sent: Wednesday, February 28, 2001 7:28 AM
Subject: Re: "Concurrent" VS...


> I think you misread my statement (in the context it was given in).  Any
usable,
> scalable process will not have developers changing the exact same files at
the
> same time.  Instead, they will work on different copies of the files.  CVS
> supports this (and it's obvious you agree).
>
> Noel
>
>
>
>
> address@hidden on 2001.02.27 18:24:21
>
> To:   address@hidden
> cc:   (bcc: Noel L Yap)
> Subject:  Re: "Concurrent" VS...
>
>
>
>
> Hi list,
>
> I have had to explain this to many people that ought to know better, so
I'm more
> than happy to perform the routine for an audience that might be forgiven
for not
> realising this. ;)
>
> >[Noel L Yap] I think the problem any VC system is supposed to solve is to
> prevent multiple people from editing the same file at the same time.
>
> If you are in a situation where there is more than one developer working
on the
> same code base, you will at some point be facing the situation of more
than one
> of them doing work on the same (set of) files.
>
> It is important to realise that NO tool can solve this problem. The only
> foolproof solution (though not necessarily free from headache) is
communication
> between developers.
>
> I like CVS because it will at least allow people to do the work,
regardless of
> whether they run into this problem later. The reality is, that it is not
likely
> to happen in even the slightest form of organisation. This yields much
better
> results than disallowing the practice (i.e. using exclusive locking).
>
> Then there is 'cvs update' and the merge process. Again, this is not to be
seen
> as a magic solution. Having CVS handle your merging for you may be a
blessing.
> It may also completely ruin the functionality of your program by breaking
> structure in your source code. What I'm saying is that CVS helps, but
nothing
> more than that. In the end there is no possible substitue for a human with
an
> accompanying brain.
>
> The way this fits in with a bit of CVS advocacy (for those of you that
have to
> explain to your boss why he shouldn't spend 40K on a Rational tool): the
same
> principle applies to any VC system out there. The difference lies in how
much
> assistance you get from the tool in solving the problem.
>
>
> I should add to this that with CVS, coupled with the average UNIX
environment,
> you can quite easily create wrapper scripts that enforce additional layers
of
> locking, to suit your business rules.
>
> I did this at my previous company, where anybody could check out, but only
a
> select few (the Release Management team) could check code in. The checking
in
> was only done for code that was accompanied by an appropriate token.
>
>
>
> TTYL,
>
> Schmolle
>
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs
>
>
>
>
>
> This communication is for informational purposes only.  It is not intended
as
> an offer or solicitation for the purchase or sale of any financial
instrument
> or as an official confirmation of any transaction. All market prices, data
> and other information are not warranted as to completeness or accuracy and
> are subject to change without notice. Any comments or statements made
herein
> do not necessarily reflect those of J.P. Morgan Chase & Co., its
> subsidiaries and affiliates.
>
>
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs
>






This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.