[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "Concurrent" VS...
Noel L Yap
Re: "Concurrent" VS...
Fri, 2 Mar 2001 07:46:07 -0500
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.
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
----- Original Message -----
From: "Noel L Yap" <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
> scalable process will not have developers changing the exact same files at
> same time. Instead, they will work on different copies of the files. CVS
> supports this (and it's obvious you agree).
> 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
> than happy to perform the routine for an audience that might be forgiven
> 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
> same code base, you will at some point be facing the situation of more
> 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
> between developers.
> I like CVS because it will at least allow people to do the work,
> whether they run into this problem later. The reality is, that it is not
> to happen in even the slightest form of organisation. This yields much
> 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
> as a magic solution. Having CVS handle your merging for you may be a
> 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
> more than that. In the end there is no possible substitue for a human with
> accompanying brain.
> The way this fits in with a bit of CVS advocacy (for those of you that
> explain to your boss why he shouldn't spend 40K on a Rational tool): the
> principle applies to any VC system out there. The difference lies in how
> assistance you get from the tool in solving the problem.
> I should add to this that with CVS, coupled with the average UNIX
> you can quite easily create wrapper scripts that enforce additional layers
> locking, to suit your business rules.
> I did this at my previous company, where anybody could check out, but only
> select few (the Release Management team) could check code in. The checking
> was only done for code that was accompanied by an appropriate token.
> Info-cvs mailing list
> This communication is for informational purposes only. It is not intended
> an offer or solicitation for the purchase or sale of any financial
> 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
> do not necessarily reflect those of J.P. Morgan Chase & Co., its
> subsidiaries and affiliates.
> Info-cvs mailing list
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.
|[Prev in Thread]
||[Next in Thread]|
- Re: "Concurrent" VS...,
Noel L Yap <=