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

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

On Wed, 2003-02-12 at 16:35, Jonathan Gossage wrote:
> ----- 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.

I think we can get close enough. The thing about CVS is, it doesn't
identify atomic checkins. To do a perfect job of figuring out when
checkins happened, you need to get a list of every change time of every
artifact  in the repository, sort them together, and identify the
clusters that were part of a single checkin. That will work - but it's
very hard to do right. 

But at the same time, the fact that there are no atomic project checkins
in CVS means that people's expectations are quite a bit
lower - because they want to be able to do roughly what they did in
CVS, and that's limited.

So, for example, if you did an import that recreated every tagged
version, and used timestamps to create daily versions
in the imported repository, that would probably be good enough: it's
very, very close to providing everything that people actually use
from CVS for history. (Look at us today: we used two methods to
find the last version: a datestamp, and a tag.)

	-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