Pegase
BeOS
Source Manager
[Introduction] [Overview]
[Quick Tour]
1. Introduction
Raphael Moll, author of PowerPulsar,
presents you his new project: Pegase,
the first and only source code manager designed from the ground for the
BeOS.
The current status of this project being delivered right now is an
advanced prototype.
The software has not yet been released and won’t go public until its
first official version. Then, it will be available as a modest commercial
application.
The following documentation conforms more to the actual specifications
of the software than to its current prototype. While the prototype is very
rude and limited, this documentation will enlighten you one a wider scope
of soon-to-be available features.
2. Overview
Pegase is the first source code manager available for the BeOS.
The software aims to be both powerful while presenting an easy-to-use
friendly interface.
Thanks to its straightforward client/server scheme, Pegase can be used
by novice users as a standalone solution and by power users as a network
maintained source database.
While designated to be full BeOS
compliant and friendly, Pegase was also designed from the raw as being
portable. The server will be available under both the BeOS
and Windows 95 environments.
The Pegase package is composed by three applications:
-
PegaseDb is the heart of the process; this background application
holds the database of source code and patiently waits for connections from
clients.
-
Pegase Server is the application that let you manage the
server, see the current defined users and projects and who is using what.
-
Pegase Client is the client-side application that the end-user
uses to manage his sources.
Currently, from the user point-of-view, Pegase Server and
Pegase Client are merged into one application.
One of the principles of Pegase is its capability to work under three
kinds of situations:
-
The novice user will want to start working with a standalone application.
In this case, he only uses the client application, and the server runs
in background on his machine.
-
For larger projects, one might want to have Pegase running as a server
on a LAN. Clients will connect to the server via TCP/IP or, more transparently,
via the Identificator daemon.
-
For distributed projects, the server can be running on a physically separate
machine or network. The user will connect to the server machine by the
Internet, using PPP. Once the connection is established, the connected
user is considered as being on the LAN. But more than that, this method
will allow the user to create batches of request offline, which will be
compressed and submitted at once to the server while being online.
When running on a LAN, Pegase will take benefit of the Identificator
daemon.
Identificator is exclusively designed for the BeOS.
This daemon listens to a TCP/IP port for specific requests and periodically
sends broadcast messages onto the network, in a desperate attempt to locate
other Identificator daemons. Each Identificator deliver human-readable
information about a machine (machine name, owner, etc.) This allows the
end application to display a list of available machine on the network to
connect to them via TCP/IP.
3. Quick Tour
Please follow this quick tour to have a complete overview of the possibilities
offered to you by the Pegase Source Manager.
3.0. Installing Pegase
To install Pegase,
just copy the pegase.zip archive to your /boot/home directory
(or, in the final version your /boot/apps directory). Then double-click
the archive and select the Expand button. When the unpacking is
terminated, close the Expander application, move the pegase.zip
file to the Trash, open the Pegase folder and you should see a Tracker
window close to the present one.
The actual online documentation can be found in the documentation
folder.
3.1. Start Pegase
Start Pegase by double-click it's icon called PegaseServer.
You will enter the logging window, where you can select the
connection mode and your logging name and password.
There are three connection modes :
-
as a standalone client/server application, running on the local machine;
this option is well suited for lonely developpers.
-
working on a LAN, where you would expect many client running for a single
server; this option is well suited for team developements.
-
working via PPP to connect to a remote LAN (or to a lonely machine via
the Internet); this option is similar to the previous one but allows you
to submit batched of queries prepared offline.
In this prototype version, you can only log in as adminstrator (username
root) on a local server. The password option is grayed since security
options are off.
Make sure the Server View radio button is active and select
Connect.
By
doing so, you start the PegaseDb daemon in background (while the
daemon starts, a small status window is displayed to give you some feedback).
This is the real server, the PegaseServer application being only
a front-end application to the background server.
3.2. Setup the Server
The first logical step is to configure the server, which is an easy step.
Once logged, you are presented the following parameter window :
At first logging time, the server will create two users : the root one
(the only and unique administrator) and a power user (named using the current
machine's name, if any).
In the non-prototype window, you should at least set a password to
the root administrator user.
The bottom part of the parameter window shows you the current state
of the background server.
The top part contains a menu and a toolbar. In this earlier version,
the toolbar is fix; but by the time of the BeDC, the full-featured XTBM
(Xavier Ducrohet's Toolbar Manager) will have been fully integrated in
the design and will provide user-customizable floating toolbars.
Basically, the parameter window let you manage users and projects.
Try clicking the New button under the user list and then the
New button under the project list.
This will bring up to new windows that you use to create or edit users
and projects.
User information covers a wide set of parameters. Some of this parameters
are read only, even by the administrator. For example, this is the case
for the creation dates. Users have an extensive and efficient set of rights.
In the system, users are identified by a unique key; note that the logging
name of the users must be unique while the real name is only an informative
field.
The project information also covers a wide variety of settable parameters,
though some parameters like the statistics are pure read-only field. Note
that this: project info window lacks the Lock checkbox and the Lock owner
field -- these will only be available in the future Extra Project Information
window.
User and Project information actually acts as non-modal, inspector
windows. They display the currently selected information and every change
is immediately active. An alert box is displayed if some user or project
information is modified while there are concurrent client accesses to the
ressource but nevertheless the action can be done without disrupting nor
disconnecting the client.
Next, go to the Server menu and select Disconnect. This
will bring you back to the logging window.
This time make sure you activate the Client View radio button
and select Connect.
You enter the real client side of the server.
3.3. Manage a Project
When you log in with the Client View, you open the following window :
This is window lets you manage a project.
You can open several projects at the same time in the final release,
but the preview release is limited to only one.
The top of the window contains the menu bar, the status line and the
same kind of XTBM toolbar than in the Server Parameter window. The main
middle part of the window is occupied by the project management lists while
the bottom part gives yet another access to the most commonly used functionalities.
A project defined by Pegase is composed by several entities, forming
an straightforward hierarchy :
-
The project is the top level of the hierarchy; it typically corresponds
to a single BeIDE project, for instance.
-
A project contains several directories, which are virtual storage
areas holding your files. Pegase directories have little to nothing to
do with the way your BeIDE project is actaully locally stored. A directory
is just a way to organise sources and easily naviguate through them. A
file or revision typically binds to a single directory, but it is accepted
to have it bind to no directory at all (in that case, it actually binds
to the top directory) or to multiple directories at once. Each directory
is associated a default working directory, which is the default user on-disk
location for issuing check-ins and check-outs.
-
Files are contained into at least one directory. A file is a recipient
for one or more file revision. Each file can override its directory's working
directory (this feature is strongly needed when a file is attached to several
virtual directories since by default the first used directory becomes the
default one for the file).
-
A revision captures the state of a file at a given time and is the
fundamental element of the management process.
The revision menu is the most interesting one.
Once one or several revisions or files are selected, it allows the
user to:
-
Edit the file or the revision directly into BeIDE, PE or StyleEdit.
-
Lock, unlock, check-in or check-out a revision (the read-only
attribute of the real file can be changed accordingly).
-
Create revision labels (that can be used to extract an image of
the project at a given date), merge several revisions or real files, compute
differences between revisions or real files, and list revisions meeting
a set of queries running on a variety of attributes.
-
Add, remove, or delete a file from a project or a directory.
At every level (project, directories, files, revisions) and given the appropriate
rights, a user can lock the whole ressource or one a subpart of it. Typically,
only revisions need to be locked via the check-out process (and unlocked
via the check-in process), but it is nevertheless possible to override
these rules.
3.4. Future Directions
Add-ons for BeIDE
One of the most promising features is to be able to lock, unlock, check-in
or check-out files directly from a project in the BeIDE.
Full Scripting Support
The client-side of Pegase will be fully scriptable under BeOS.
The PegaseDb background server is not scriptable since it needs to
be accessed by a Pegase front-end.
Portability
While listen in the future direction section, the portability of PegaseDb
is real. PegaseDb source is based on a cross-platform low-level API. Pegase
Server is BeOS
specific.
Both PegaseDb and Pegase Server can run under BeOS
PR2 on PPC boxes and need just a light recompile to run under BeOS
R3 for either PPC or Intel x86 boxes.
Pegase is split into these two entities for connectivity reasons and
portability reasons. PegaseDb runs under the BeOS using either local BMessenger
or remote socket connections. PegaseDb can run under Windows using only
socket connections.
Using socket connections, every version of Pegase Server will be available
to connect to any other version independently of the platform.
4. Extra Information
Pegase,
the Pegase Logo and other boring stuff are copyright of Raphael MOLL.
BeOS, the BeOS logo and some Windowished icons are the property of
their respective owners.
The interface prototyping was done using Interface Elements under BeOS
PR2. Thanks to A. Mezei for his comprehensive support. Thanks to Sander
Stoks for his nicer and nicer Becasso paint application. And of course
thanks to the PowerTeam members for everything else.
Pegase should be available in early beta versions by mid-1998.
Links :
(end of this beloved HTML document).
First Release : 4 March 1998.
Updated : 4 March 1998
(early in the morning, you know what I mean ;-))