Re: [stellation-res] The server, and self-hosting

["Jonathan Gossage" <jonathan@xxxxxxxxxxxxxx>]

----- Original Message -----
From: "Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>
To: "Stellation-res" <stellation-res@xxxxxxxxxxxxxxx>
Sent: Wednesday, February 12, 2003 4:11 PM
Subject: Re: [stellation-res] The server, and self-hosting


> On Wed, 2003-02-12 at 15:48, Jonathan Gossage wrote:
> > ----- Original Message -----
> > From: "Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>
> > To: "Stellation-res" <stellation-res@xxxxxxxxxxxxxxx>
> > Sent: Sunday, February 09, 2003 9:38 PM
> > Subject: RE: [stellation-res] The server, and self-hosting
> >
> >
> > > On Sun, 2003-02-09 at 21:10, Jonathan Gossage wrote:
> > > > > >-----Original Message-----
> > > > > >From: stellation-res-admin@xxxxxxxxxxxxxxx
> > > > > >[mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Mark C.
> > > > > >Chu-Carroll
> > > > > >Sent: February 9, 2003 2:07 PM
> > > > > >To: Stellation-res
> > > > > >Subject: [stellation-res] The server, and self-hosting
> > > > > >
> > > > > >
> > > > > >
> > > > > >So, finally, the Stellation server machine is pretty much ready
to
> > > > > >go. The Eclipse folks have set up the machine, and once I do a
bit
> > > > > >of set-up, it will be unveiled.
> > > > > >
> > > > > >Based on my work over the last couple of days, there are a few
> > > > > >things that I'd like to finish before we really start using it.
I'll
> > > > > >provide my own list at the end of this message, and I'd like to
know
> > > > > >what others think are essential before we start really using it.
> > (Just
> > > > > >for info sake: even after we're self-hosting, I plan to mirror
> > changes
> > > > > >into the public CVS for backup.)
> > > > > >
> > > > > >I'd also like to propose that initially, we not have an anonymous
> > > > > >account on the server. For at least the first month or so, I'd
like
> > > > > >for people to have to explicitly request accounts on the server.
(The
> > > > > >accounts will be set up with read-only privileges.) There
> > > > > >are three reasons for this. First, it will somewhat limit the
traffic
> > > > > >pounding on the server. Second, with the ACL support being
relatively
> > > > > >untested, it gives us a bit of added security - if something goes
> > > > > >wrong, we can tell *who* did it. And finally, it gives us a bit
> > > > > >more information, so that if a certain user crashes the server,
we
> > > > > >can reproduce the sequence of operations that they performed
> > > > > >leading up to it.
> > > > > >
> > > > > >I've been skimming the code, and the one thing that worries me is
ACL
> > > > > >support. I've written a lot of tests that really pound on the ACL
> > > > > >support in the repository, but the command line ACL support is
> > > > > >completely untested. Reading the code, the command-line ACL
> > > > > >stuff is pretty complicated, and with no tests, I have absolutely
> > > > > >no trust that it's bug free. So I'd like to do some code cleanup
and
> > > > > >some testing to make sure that it's working correctly.
> > > > > >
> > > > > >Our Eclipse support is currently quite weak. The working Eclipse
> > plugin
> > > > > >is based on Jim's first attempt, which was done by wrapping the
> > > > > >command-line in an Eclipse veneer. This was not entirely
successful,
> > > > > >because the command-line and the Eclipse workspace have very
> > different
> > > > > >deep assumptions. The plugin mostly works, except that the merge
> > support
> > > > > >does *not* use the Eclipse sync view for conflicts. It places a
> > textual
> > > > > >conflict marker, just like the CVS command-line, and then Eclipse
> > > > > >generates a cascade of syntax errors around the marked conflict.
> > > > > >Personally, I'm willing to live with this in order to get us to
start
> > > > > >using Stellation.
> > > > > >
> > > > > >Is there anything that anyone else considers crucial before we
start
> > > > > >up a Stellation server?
> > > > > >
> > > > > > -Mark
> > > >
> > > > Do you think we have sufficient support to handle code audits at
this
> > point?
> > >
> > > We have full branch support. So for doing audited work, we can fork
> > > branches named after the bugzilla bug that they're related to; check
in
> > > the changes there; and then pass the branch to someone else to be
> > > committed back into the main branch.
> > >
> > > > Will it be possible for interested parties to continue to use CVS if
we
> > > > experience early problems?
> > >
> > > I'm planning to do mirroring of changes from Stellation to CVS. If
it's
> > > at all possible, I'd like to avoid the dual-mirroring situation, where
> > > there are concurrently changes happening in both CVS and Stellation,
> > > and I need to keep things in synch manually. But the changes will be
> > > mirrored out to CVS, so that if we experience problems, we can easily
> > > temporary back out to CVS. I'd just like to be sure to do that as a
> > > group: if we have insurmountable trouble, we'll all go back to CVS.
> > >
> > > -Mark
> > >
> > It seems to me that a utility that could import a CVS repository into
> > Stellation could be useful. Caveat, I have not looked at the CVS API's
so I
> > have no idea how large an undertaking this might be.
>
> Dave looked into it last summer or so, and at some point, had a script
> that kinda-sorta worked. But as far as I know, he never finished it.
>
> There aren't much in the way of APIs for CVS. What Dave did, as I
> remember, was use the CVS command that listed tags in chronological
> order. He did a checkout of each tagged version into a stellation
> workspace; then did an "svc synch", and then check-in again. Gail
> Murphy at UBC has a tool called Hipicat, which I think has source code
> available, which uses change times to identify all of the checkins,
> which would give a more precise change history than Dave's simple tag
> mechanism. But Hipicat is *much* more complicated than what Dave was
> working on.
>
> It shouldn't be an overly difficult task to rewrite a script like that,
> and it's something that would be a valuable thing to provide with the
> system.
>
> On the other hand, it does nothing to simplify the problem of
> maintaining CVS and Stellation repositories in parallel and keeping
> them synched - this was just a way of initializing a Stellation
> repository to contain the contents of an older CVS repos.
>
> -Mark
>
I was thinking of it in terms of a one time import. But I do think that it
will not be well received unless it can do a first class job of bringing the
full history across.

Regards

Jonathan