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

["Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>]

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
	
-- 
Mark Craig Chu-Carroll,  IBM T.J. Watson Research Center  
*** The Stellation project: Advanced SCM for Collaboration
***		http://www.eclipse.org/stellation
*** Work: mcc@xxxxxxxxxxxxxx/Home: markcc@xxxxxxxxxxx