[Gnome-devtools] gnome-vcs: the start
- From: Dirk Vangestel <dirk_vangestel yahoo com>
- To: gnome-devtools helixcode com
- Subject: [Gnome-devtools] gnome-vcs: the start
- Date: Sun, 5 Nov 2000 06:20:35 -0800 (PST)
Hey,
I want to start on gnome-vcs, the version control
component of our beloved development tools.
I have written down my ideas on the subject, and I
would apreciate it if everyone could post their
ideas/comments/criticism. I tink this list can be used
(since it seems to be almost dead anyway)...
Dirk
__________________________________________________
Do You Yahoo!?
Thousands of Stores. Millions of Products. All in one Place.
http://shopping.yahoo.com/
gnome-vcs: What and why?
Almost all projects these days have some kind of version control. Whether
the project is open source or commercial, version control is present
everywhere.
There are different kinds of version control systems available, commercial
or free. Those systems have similar functionality, but the way they work
is slightly different. Switching regularly between 2 or more system can be
quite confusing.
Most of the version control systems are based on a command line system,
although often a graphical user interface is present. Usually they also
have some kind of integration with a development environment.
The main idea behind gnome-vcs is to provide a common interface to
all these version control systems. This interface can then be used in
different kinds of applications like editors or IDEs. The advantage of
having a common interface is that a user only has to learn one set of
commands but still has access to all version control systems.
Gnome-vcs only provides a programmatical interface. It is not the intent
to write command-line tools although that might be a useful extension
later.
The implementation will be based on a CORBA interface, implemented using
Bonobo. There are 2 parts to the implementation: a common interface and
an implementation of this interface for all supported version control
systems. To test the validity of the interface, 2 very different version
control systems will be implemented: cvs and ClearCase(1). cvs is a widely
used system in the free software world, while ClearCase is its counterpart
for the commercial software world.
Details are still sketchy at best, but here goes.
The common interface is the most important part. It has the following
functions:
- Select version control system. Because there can be different version
control systems installed on any single system, this function allows a
user to select which he wants to use.
- Connect to vcs. This allows a user to 'log in' to the vcs.
For cvs this will be the actual login.
For ClearCase this might just be a selection of the vob directory.
- Connect to project. In a vcs database, there are most likely several
projects present. A user has to select which project to connect to.
For cvs, the system can check whether the most current version is present
on the user's system. The user will also be able to select a tag.
For ClearCase, the user can edit his configspec so the correct version is
selected.
- New project. Using this command, the user can create a new project in the
vcs database. This will usually just create a directory in the vcs database.
- Check out. This gets a file out of the vcs database and allows a user to
edit the file.
For cvs, this operation probably does nothing, except maybe to check
whether the most recent version is present.
For ClearCase, the file will be checked out (in the ClearCase meaning).
- Undo check out. Using this operation, a check out can be cancelled. The
changes done to the file will not be incorporated into the vcs database.
For cvs, this will be a 'release'.
For ClearCase, the unco command will be run.
- Check in. If the changes are to be kept, a file needs to be checked in.
It will be stored in the vcs database. The user is asked to provide a
log which details the changes he did in the file.
For cvs, this will be a commit. Or at least, the file will be marked
to be committed. Usually single files are not committed in cvs, which
makes this command a bit awkward.
For ClearCase, the file will be checked in.
- Attach label. This command will create a label and put it on all files
which are currently active.
For cvs, the command will put a tag on the current project.
For ClearCase, a label type will be made and it will be put on all files.
- Make branch. This command will make sure that all changes from this time
on will be put on a branch.
For cvs, a branch will be made.
For ClearCase, a branch will be made and the configspec will be adjusted.
- Show changes. Allows a user to inspect the changes that have been made
to a previous version (commonly known as a diff).
For cvs, the diff command will be used.
For ClearCase, the diff command will be used.
- Show change history. A user can add comments when creating a new version of
a file, and this command shows the comments added to previous versions.
For cvs, this will be a 'log'.
For ClearCase, this will be a 'lshistory'.
- Properties. The user can get properties of the project or single files.
All labels as well as the currently selected version will be displayed.
For cvs, this will be a 'status -v'.
For clearcase, this will be a 'des' or 'lsvtree'.
- Add file to vcs. The user has to manually add a new file to the project.
For cvs, this will be an 'add'.
For ClearCase, this will be an 'mkelem'.
- Remove file from vcs. The user can choose to removed a file from the
vcs database using this command.
For cvs, this will be a 'remove'.
For ClearCase, this will be a 'rmelem'.
- Disconnect. Using this command, the user can disconnect from a vcs database.
For cvs, this will do a logout and probably a commit (if the user wants to).
For ClearCase, nothing needs to be done.
(1) ClearCase is a product of Rational Software.
Dirk Vangestel
dirk_vangestel yahoo com
Version 1. Nov 05, 2000.
[Date Prev][
Date Next] [Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]