Very Computer

Can anyone give me some ideas on how to manage source code when members of
the same development team are not at the same physical location?  I've seen
the posting for the Java version control software which was quite
interesting.  In addition to this, what other techniques are used.

Thanks in advance,

Peter

You can keep all the source files in a central pool called repository
and to be made available to the users at different locations.
There are CM tools available to manage this repository;

You can think of CVS 1.9.14 if your project is small.
CVS keeps the repository in a single location and users at different
locations
can access and update with its "-d" option.

You can think of Clearcase & Multisite if your project is quite big and
more locations involve.  These tools allow to keep repository in many
locations and synchronize the changes made into them.

Regards
Suresh Kumar

You are more than welcome to explore R-Sea-Yes. We have people using it
around the globe on many platforms (VAX, ALPHA, UNIX etc.) with Windows
95/NT as the driver.

So long as you can define the remote machine (LAN or WAN) as a virtual
drive it is transparent to the software. This may be done using Pathworks
(DEC machines) NFS or any reasonable remote access tool.

--
Lisa - Marketing Manager
SEA  Software Ever After
=======================================
Quality software is just the beginning...
http://www.home.aone.net.au/sea

Quote:> Can anyone give me some ideas on how to manage source code when members
of
> the same development team are not at the same physical location?  I've
seen
> the posting for the Java version control software which was quite
> interesting.  In addition to this, what other techniques are used.

> Thanks in advance,

> Peter

I'm new in this group, and I've missed the posting on
a Java version control software. Where can I read more
about it?

Today we're using RCS, but are having problems using it
over all our distributed development sites. Does anybody know
about an extension to RCS for multi-site development.
We've tried using a mailforward script to do co/ci.
It doesn't work very well though.

Our present development platform is HP-UNIX, but we will soon introduce
NT. Therefore we'd prefer not to put too much money and/or effort into
moving to another revision control system right now. That's why we want
some simple but trustworthy solution meanwile.

Thank you!

/Thomas ELiasson

[Warning -- vendor carping.]

Quote:>You are more than welcome to explore R-Sea-Yes. We have people using it
>around the globe on many platforms (VAX, ALPHA, UNIX etc.) with Windows
>95/NT as the driver.
>So long as you can define the remote machine (LAN or WAN) as a virtual
>drive it is transparent to the software. This may be done using Pathworks
>(DEC machines) NFS or any reasonable remote access tool.

Christopher
----
Christopher Seiwald     Perforce Software          1-510-864-7400

I would also like to hear what R-Sea-Yes has to say.

-Ron Perrella

Thanks,
Mark Crowder        
Texas Instruments, SPDC Computer Systems Engineering

msg : CRDR
ph  : (972) 995-3799
pg  : (972) 598-3187
fx  : (972) 927-4449
--------------------------------------------------------

Quote:> > CVS keeps the repository in a single location and users at different
> > locations can access and update with its "-d" option.
>    What is your definition of "small" in this case?  We have
> about thirty (30) developers working on a project (unix-based) and
> are considering CVS.

CVS certainly has projects with at least 30 developers.  Cygnus has at
least 50 full-time developers and FreeBSD has something like 100
developers (not full-time).  In both cases the developers are
geographically dispersed.  For more projects using CVS, see:
    http://www.cyclic.com/cyclic-pages/projects.html

-- mark

There are a number of systems which will provide this kind of support and the
previous responses to this message list several of them.  My company, StarBase,
sells a product called StarTeam which was designed specifically for distributed
development.  StarTeam 2.1, which can be downloaded from our web site for
evaluation, can be used for versions control, defect tracking and threaded
conversation over any TCP/IP connection, including the Internet.  For those
users who prefer to use a web browser to interact with the StarTeam repository,
the StarTeam VirtualTeam Server's Web Connect component provides this type of
access.  Very convenient for customers to report defects and participate in
threaded conversations with the development team.  StarTeam 2.1 is currently a
Windows 95/NT only product.

If you are on other platforms you will need StarTeam 3.0's Universal (also
known as UNIX command line) edition, which is a client component written in
Java.  We are currently beta testing this product and plan to release it around
the end of the year.  Initially the Universal edition will only support a basic
command line for version control, but a full Java based UI is planned for
release later in '98.

Hope this helps.

Steve Reynolds
Director of Product Management - StarBase
 http://www.starbase.com

A disconnected development scenario has the developer put their work
area on a laptop or removeable media like a Jaz for use at home or out
in the field.  Changes they make to files within the work area are
picked up when they reconnect the work area and perform a "Reconcile".
This compares the contents of the work area with the original
configuration in the repository and then prompts for the action that the
developer wants to take: check out and update versions not already
checked out, update the repository if already checked out, and/or ignore
the changed version.  The disconnected scenario provides for file
versioning and builds done in the field or at home.

A dial up scenario puts a Continuus client on a remote workstation which
then connects back to the central server using SLIP, PPP or other WAN
transport.  Client-server model is used and includes file transfer over
the socket instead of remote filesystem mounts like NFS.  You only take
the initial hit for creating the work area on the remote workstation.
Work area <-> repository updates push only the files that have changed
over the dial up line.  The initial work area hit may be avoided by
building the work area at the Continuus Server site and then
disconnecting the workstation or media for dial up use in the field.
The dial-up/Wan scenario adds full functionality to the remote developer
including the ability to track checkout to their tasks as they checkout
and to create, modify and promote tasks and P/T change requests.

The Distributed Change Management (DCM) option allows two or more
Continuus servers to connect and synchronize over LAN, WAN or tape
transfer.  Using DCM you may designate that the entire repository be
kept in synch or only the parts that may be of interest to remote
sites.  The developer access is transparent.  Our parallel development
notification extends to include notifications over the multiple
repositories.  The DCM scenario allows for higher responsiveness at the
remote sites since they are covered by their own servers.  It also makes
more efficient use of the limited WAN or dial-up bandwidth.

--
Bill Sharer
Continuus Software

703-848-9272 (Vienna VA usa)

Yes. It is much faster than most of its competitors.

Check out the new PVCS SiteSync and their upcoming release of Version
Manager which actually allows developers to check code out over the
internet. You may want to check out their newsgroups....
InterSolv.pvcs.general      or InterSolv.pvcs.support.

Do you have benchmark data that you'd like to share with us, or should
we take your word on this?

Cheers,
Steve
-----
Steve Thomas
Lucent Technologies - Bell Labs