Subject | source control - marion etc |
---|---|
Author | Reed F. M. |
Post date | 2000-01-25T21:09:22Z |
As the person who was responsible for source
control and builds at IB until very recently, I'll try to
shed some light on the situation with source control at IB.
A number of people, including Ann, have suggested that
either everybody or at least NewCO could continue using
marion. The problem with this is that even before all
this happened marion had long been in disrepair, and we had
reached it's limits in a number of ways. We were in the
process of switching to Rationals ClearCase. When I left,
the source was stored in marion and automatically mirrored into
ClearCase.
ClearCase is an excellent system in many ways, but suffers from:
1) high licensing cost
2) high administration and configuration overhead
3) not well suited to distributed development. (You can have
multiple sites, but each site needs a skilled clearcase
admin.)
These aspects make ClearCase pretty much unsuitable as the
universal code control system for open source IB.
Marion is a decent system, however, it was not maintained
for a very long time, and lacks some essential features.
It stores diffs, but does not allow you to reconstruct previous
versions without >MANUALLY< applying the diffs in order. Diffs
for different changes are created using different diff programs
(how's that for a tongue twister ?), and a misconfigured
developer workstation might cause no diffs at all to be
stored for a change. Marion also does not
support >ANY< form of branching or parallel development, so
branches and code freezes are done by making a backup of the GDB.
This was a serious drawback before open source, and would
be much worse if there are all kinds of patch versions and
even more platforms.
The existing system at IB worked as follows:
There was one main marion.gdb (known as 'dev')
The dev marion contains the source for the most recent developments
on the primary platforms (NT, Solaris and HP-UX, in recent times),
up until final beta of a particular release. At that point, a copy
is made (we'll call it v6.0), and any further changes required for
the release are made to both v6.0 marion and dev marion. Additionally,
any changes for 6.x or 7.x are made to dev only. After v6.0 is
released, the v6.0 marion could be used as the basis for a bug fix
release, and any 6.0 ports to secondary platforms. If 6.0 linux
was started, it would begin as a copy of v6.0. When finished, the linux specific changes would be merged back into dev, so that the
next linux port would be easy. As you can see, this becomes
increasingly complex as there are more releases on more platforms.
Marion also does not support a hierarchy (directory structure) that
is more than two levels deep.
None of marions problems are insurmountable, and in hindsight,
it might have been easier to make marion do what we wanted
rather than switch to ClearCase (which has a tremendous overhead
for configuration). Marion could be made into a good source control
system, but it is a LONG way from being comparable with
things like ClearCase and Perforce.
My feeling is that a solution which mirrors (both ways)
between marion and CVS (or any two source control systems) is
not a very good idea. If a suitable CVS configuration for IB
can be created, then everyone (including the NewCO development
staff) should use it. Maintaining two source controls systems
is always more work that maintaining one. If marion is to be used
at all, it needs someone dedicated to maintaining it, and making
the changes required for it to work in the new situation.
IB development is not particularly dependent on marion. I had
complete builds working from clearcase, nightly, in parallel
to the official builds. The makefiles for the clearcase version
clean up a lot of cruft from the old system. Since they are 99.9%
GNU make syntax, they would be a good starting point for open
source IB. The one really neat thing about marion is being able
to make SQL or QLI queries on the source and history directly. ;-)
The ClearCase query language sucks compared to a real RDBMS.
Ann's comments about 'eating our own dogfood' by using
a IB based source control system are valid. However, this
is dependant on someone actively maintaining the system.
Best regards,
-reed
Jason Whorton wrote:
_________________________________________________________
Get your own FREE portalofevil.com Email account at...
http://www.portalofevil.com
PortalofEvil.com - Websites by the insane for the insane.
_________________________________________________________
control and builds at IB until very recently, I'll try to
shed some light on the situation with source control at IB.
A number of people, including Ann, have suggested that
either everybody or at least NewCO could continue using
marion. The problem with this is that even before all
this happened marion had long been in disrepair, and we had
reached it's limits in a number of ways. We were in the
process of switching to Rationals ClearCase. When I left,
the source was stored in marion and automatically mirrored into
ClearCase.
ClearCase is an excellent system in many ways, but suffers from:
1) high licensing cost
2) high administration and configuration overhead
3) not well suited to distributed development. (You can have
multiple sites, but each site needs a skilled clearcase
admin.)
These aspects make ClearCase pretty much unsuitable as the
universal code control system for open source IB.
Marion is a decent system, however, it was not maintained
for a very long time, and lacks some essential features.
It stores diffs, but does not allow you to reconstruct previous
versions without >MANUALLY< applying the diffs in order. Diffs
for different changes are created using different diff programs
(how's that for a tongue twister ?), and a misconfigured
developer workstation might cause no diffs at all to be
stored for a change. Marion also does not
support >ANY< form of branching or parallel development, so
branches and code freezes are done by making a backup of the GDB.
This was a serious drawback before open source, and would
be much worse if there are all kinds of patch versions and
even more platforms.
The existing system at IB worked as follows:
There was one main marion.gdb (known as 'dev')
The dev marion contains the source for the most recent developments
on the primary platforms (NT, Solaris and HP-UX, in recent times),
up until final beta of a particular release. At that point, a copy
is made (we'll call it v6.0), and any further changes required for
the release are made to both v6.0 marion and dev marion. Additionally,
any changes for 6.x or 7.x are made to dev only. After v6.0 is
released, the v6.0 marion could be used as the basis for a bug fix
release, and any 6.0 ports to secondary platforms. If 6.0 linux
was started, it would begin as a copy of v6.0. When finished, the linux specific changes would be merged back into dev, so that the
next linux port would be easy. As you can see, this becomes
increasingly complex as there are more releases on more platforms.
Marion also does not support a hierarchy (directory structure) that
is more than two levels deep.
None of marions problems are insurmountable, and in hindsight,
it might have been easier to make marion do what we wanted
rather than switch to ClearCase (which has a tremendous overhead
for configuration). Marion could be made into a good source control
system, but it is a LONG way from being comparable with
things like ClearCase and Perforce.
My feeling is that a solution which mirrors (both ways)
between marion and CVS (or any two source control systems) is
not a very good idea. If a suitable CVS configuration for IB
can be created, then everyone (including the NewCO development
staff) should use it. Maintaining two source controls systems
is always more work that maintaining one. If marion is to be used
at all, it needs someone dedicated to maintaining it, and making
the changes required for it to work in the new situation.
IB development is not particularly dependent on marion. I had
complete builds working from clearcase, nightly, in parallel
to the official builds. The makefiles for the clearcase version
clean up a lot of cruft from the old system. Since they are 99.9%
GNU make syntax, they would be a good starting point for open
source IB. The one really neat thing about marion is being able
to make SQL or QLI queries on the source and history directly. ;-)
The ClearCase query language sucks compared to a real RDBMS.
Ann's comments about 'eating our own dogfood' by using
a IB based source control system are valid. However, this
is dependant on someone actively maintaining the system.
Best regards,
-reed
Jason Whorton wrote:
> NOTE: When I say CVS I mean CVS and comparable solutions...[...]
>
> Touching on this some gave me an idea about some of the other issues being
> discussed.
>
> Would it be possible for newCo to use three basic levels here?
>
> 1) The core engine team could continue using the Marion source control
> system.
> 2) The serious developers at large would be setup to operated through the
> CVS interface.
> 3) The not so serious could simply use email, word of mouth, etc.
>
_________________________________________________________
Get your own FREE portalofevil.com Email account at...
http://www.portalofevil.com
PortalofEvil.com - Websites by the insane for the insane.
_________________________________________________________