Eclipse Community Forums: Technology Project and PMC » How does Stellation store revisions?

Help

Home

Home » Eclipse Projects » Technology Project and PMC » How does Stellation store revisions?

Show: Today's Messages :: Show Polls :: Message Navigator

How does Stellation store revisions? [message #31954]

Fri, 18 October 2002 20:12

Eclipse User

Originally posted by: wlandry.ucsd.edu

Greetings,

I'm a developer for Arch[1], so I've been looking how other SCM's
implement things. I've read many of the documents on the web, but I still
don't completely understand some of the internals of Stellation. I'd
appreciate it if someone could enlighten me.

1) As I understand it, Stellation's eventual plan is to break code up into
parts based on the syntax of the language, and then do revision management
on those parts. Right now, it only operates on files. Does that mean
that I could use it right now for contents which are difficult or
impossible to parse?

2) I assume that somewhere in the database is a complete copy of some
revision of a file. Different revisions are then created by applying
patches.
a) Does that mean that whenever you run Stellation, all of the
revision + patches are loaded into memory?
b) Which revision do you store? The first revision, the last active
revision, the last revision for each branch, or something completely
different?

3) It seems that when you commit changes, you don't have to explicitly
tell Stellation which files you edited. That is, you didn't have to check
out a file for editing before editing it. Does that mean that Stellation
does a recursive diff to find out what changed?

4) Is it possible to set up a public, read-only repository? If so, does
it use the normal authentication mechanism (so you have to set up a
special user with read-only priviledges), or does it bypass it entirely?

Thanks,
Walter Landry
wlandry@ucsd.edu

[1] http://www.fifthvision.net/Arch

Report message to a moderator

Re: How does Stellation store revisions? [message #32026 is a reply to message #31954]

Fri, 18 October 2002 21:43

Mark C. Chu-Carroll

Messages: 32
Registered: July 2009

Member

We'd prefer to move Stellation discussions into
eclipse.technology.stellation, because this group is usually flooded with
posts by people who are unable to read a newsgroup description before
posting.

On Fri, 18 Oct 2002 16:12:29 -0400, Walter Landry wrote:

> Greetings,
>
> I'm a developer for Arch[1], so I've been looking how other SCM's
> implement things. I've read many of the documents on the web, but I
> still don't completely understand some of the internals of Stellation.
> I'd appreciate it if someone could enlighten me.
>
> 1) As I understand it, Stellation's eventual plan is to break code up
> into parts based on the syntax of the language, and then do revision
> management on those parts. Right now, it only operates on files. Does
> that mean that I could use it right now for contents which are difficult
> or impossible to parse?

Now and always, yes. If you provide a language parsing component to break
things into small units, we'll use it. If you don't, we'll just work with
the file, like any other SCM system.

> 2) I assume that somewhere in the database is a complete copy of some
> revision of a file. Different revisions are then created by applying
> patches.

Nope. We don't use a patch based storage representation. We use a storage
mechanism called in-place-delta, similar to clearcase. It's a very
different storage mechanism.

For text storage, the basic idea is, we have a table containing all of
the lines that have ever occured in any version of an artifact. Then
we have another table that tells us which lines appear in which order in
a particular version of the file.

> a) Does that mean that whenever you run Stellation, all of the
> revision + patches are loaded into memory?

Nope. Just the requested version. The database takes care of the rest.

> b) Which revision do you store? The first revision, the last active
> revision, the last revision for each branch, or something
> completely
> different?

Something completely different.

> 3) It seems that when you commit changes, you don't have to explicitly
> tell Stellation which files you edited. That is, you didn't have to
> check out a file for editing before editing it. Does that mean that
> Stellation does a recursive diff to find out what changed?

Roughly speaking, yes. Actually, we store a timestamp and an SHA hashsum
for each artifact in the system. Then when a checkin occurs, we check
each file to see if it's timestamp has changed. If it has, then we
compute the hashcode, and check it. If the hashcode doesn't match, then
it's different, and needs to be checked in.

> 4) Is it possible to set up a public, read-only repository? If so, does
> it use the normal authentication mechanism (so you have to set up a
> special user with read-only priviledges), or does it bypass it
> entirely?

For the version currently in CVS, no you can't. But for the version
currently on my laptop being tested, you will be able to.

The way to do it will be standard authentication, and standard use of
the access control mechanisms. There's no special case for an anonymous
user: anonymous is just another username, whose password can be an empty
string, and who is permitted by the system access control lists to have
read-only access.

It's also pretty flexible. You can put multiple projects into a single
repository, and grant anonymous users read-only access to one project,
but no access to another. Or you can give anonymous users checkin
privileges to an open branch of the project, but not the main branch...

-Mark

--
Mark Craig Chu-Carroll, IBM T.J. Watson Research Center
*** The Stellation project: Advanced SCM for Collaboration
*** http://www.eclipse.org/stellation
*** Work Email: mcc@watson.ibm.com ------- Personal Email: markcc@bestweb.net

Report message to a moderator