aspgpas@cid.aes.doe.CA (Peter Silva) (07/17/90)
I'm looking for a portable source code manager that lets multiple users modify the same file at the same time. Two+ users should be able to get the same mod file (via command like SCCS "get"), make changes, and only know that someone else was working on the same file if the two happen to modify the same LINES of code. In that case, an error message would be given when the second modifier of the lines tried to return his mod (using a command like SCCS 'delta'). The manager should also maintain multiple variations of a single package. The most obvious example of a 'variation' is for hardware dependencies, but there are many others. We would like to be able to make changes that affect a specific number (one, some, all) variations. RCS and SCCS meet neither of these requirements. Public domain, shareware and commercial software are all of interest. I have read a paper about SUN's translucent file system which sounded interesting, and elegantly supports multiple versions. I don't remember it dealing with concurrent editing. Experiences, recommendations, etc... wanted. Will post result if sufficient interest shown. Advance thanks for your help. Peter Silva OS Support psilva@cid.aes.doe.ca Dorval Computer Centre Atmospheric Environment Service -- Peter Silva psilva@cid.aes.doe.ca (514) 421-4692
ssdken@watson.Claremont.EDU (Ken Nelson) (07/18/90)
In article <1990Jul17.161924.8248@cid.aes.doe.CA>, aspgpas@cid.aes.doe.CA (Peter Silva) writes: |> I'm looking for a portable source code manager that lets multiple users |> modify the same file at the same time. Two+ users should be |> able to get the same mod file (via command like SCCS "get"), |> make changes, and only know that someone else was working on |> the same file if the two happen to modify the same LINES of code. |> Are you sure you want to do this? Doesn't one line of code affect the behavior of another? When I make changes, I make them based on assumptions about the behavior of other lines of code in the module/program. If somebody else is making changes to that behavior, watch out. Ken Nelson
ghoti+@andrew.cmu.edu (Adam Stoller) (07/19/90)
Try taking a look at CVS (I believe it was posted to comp.sources.unix about a month ago?) -- there was an article about it in the USENIX proceedings (San Diego?) not too long ago. With the limited experience I've had in using it - it appears to work reasonably well - however it certainly hasn't been thoroughly tested where I work. --fish
emv@math.lsa.umich.edu (Edward Vielmetti) (07/19/90)
In article <0ad_FFS00as9IEGkUM@andrew.cmu.edu> ghoti+@andrew.cmu.edu (Adam Stoller) writes:
Try taking a look at CVS (I believe it was posted to comp.sources.unix
about a month ago?) -- there was an article about it in the USENIX
proceedings (San Diego?) not too long ago.
With the limited experience I've had in using it - it appears to work
reasonably well - however it certainly hasn't been thoroughly tested
where I work.
cvs can be had from prep.ai.mit.edu or osu-cis (or wherever fine gnu-ware
is available). the architecture looks sound, some operations are said
to be slow, it assumes a "disk space is cheap" model. oh and the sources
are Free as in Gnu Public License.
--Ed
Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>
comp.archives moderatorrh@smds.UUCP (Richard Harter) (07/19/90)
In article <7858@jarthur.Claremont.EDU>, ssdken@watson.Claremont.EDU (Ken Nelson) writes: > In article <1990Jul17.161924.8248@cid.aes.doe.CA>, > aspgpas@cid.aes.doe.CA (Peter Silva) writes: > |> I'm looking for a portable source code manager that lets multiple users > |> modify the same file at the same time. Two+ users should be > |> able to get the same mod file (via command like SCCS "get"), > |> make changes, and only know that someone else was working on > |> the same file if the two happen to modify the same LINES of code. > Are you sure you want to do this? Doesn't one line of > code affect the behavior of another? When I make > changes, I make them based on assumptions about the > behavior of other lines of code in the module/program. > If somebody else is making changes to that behavior, > watch out. It depends very much on the nature of the changes, the nature of the code (and its language), and whether there is a single line of development or multiple lines. Within a single line of development you really always want to know if there are other people working on the same file. Parallel change is *relatively* safe if (a) the changes being developed are well defined, (b) they are independent in function and impact, and (c) the code being modified is not tightly coupled. In short, you need well structured code and a good disciple of change control. A factor which is frequently overlooked is that changes are made to programs or software systems -- files are simply one of the ways that software is modularized. Changes in separate files, developed in parallel, can interact with each other if the coupling between them is affected. As a general rule parallel development of changes works best if the code is highly modular, coupling is disciplined, and there is a strong discipline of change control in which changes themselves are modular with a minimum of coupling. It is also *very* important that merged changes be rigorously tested! No formal mechanism of merging can guarantee that the merged code is correct. -- Richard Harter, Software Maintenance and Development Systems, Inc. Net address: jjmhome!smds!rh Phone: 508-369-7398 US Mail: SMDS Inc., PO Box 555, Concord MA 01742 This sentence no verb. This sentence short. This signature done.