RE: [Squeak-VMdev] RE: Pending 3.2 and VM sources @ sourceforge

[<gor...@bl...>]

Rob Withers <rwi...@at...> wrote:
> gor...@bl... wrote:
> > Well, if you are interested in hacking on sqcvs - which is a CVS
> > pserver-client/server protocol implementation - then I should write down
> > an email for you with the most pressing todo-list. Most of those todos
> > are pretty damn easy to implement so I think it is a "rewarding point in
> > time" to jump in! :-)
> > 
> > Sqcvs is meant to be "plugged in" with VMMaker making it even easier to
> > build your own VM. Then of course - a nice Morphic UI on top of Sqcvs
> > wouldn't hurt - then we have our very own supercrossplatform CVS client!
> > :-)
> > 
> > One thing to start with would be to integrate it in FileList and
> > friends. That would perhaps be nice. Anyway - if you are still
> > interested then I can whip up an email to get you started. 
> > 
> > Regarding cvstproj - which is a different thing - you should talk to
> > Martin Kobetic. Currently it looks like Avi Bryant is building something
> > along the same lines as cvstproj (same goal, different approach) so you
> > may want to talk to him too.
> 
> Hey Goran,
> 
> I would welcome the email you mention writing, basically a roadmap of
> integrating cvs support into Squeak.  As sqcvs currently stands, we can

Sure.

> probably d/l the trunk to the file-system, then generate our code,
> right?  Otherwise we should get that working, first.  Following that,

That already works. I posted Tim a couple of lines of code that does
that and he said it worked fine. :-)
The only thing stopping us from having such a "button" in VMMaker is
that such a checkout doesn't create compatible CVS clientside "state"
files, so you can't use another CVS client on that workingcopy. Oops.
=Not very useful. That is one of the things on the todo.

> you mention other protocol features (commit, etc), then a UI evolving
> through increasing complexity.

Commit actually already works. It's basically add/remove that is missing
today.
Well, some other things of course...

> I am certainly up for helping you get the VMMakerTool using cvs, but I

Cool. I will write that roadmap.

> am not so sure about the rest.  It seems we have competing
> implementations, already.  I don't have a whole lot of time, and it has

Eh, the rest? Competing implementations?

> to be spread out, but I can help.
> 
> > "branched tipped with 3.2g-experimental-protected-memory?" - I am not
> > following your english here.
> 
> What english?  :)
> 
> > No problem - keep hammering, hopefully other people not versant in CVS
> > will learn something too! :-)
> 
> I think the important point to agree on is when to tag the main trunk
> with a root.  I feel this should be done at major release points, or
> experimental branches only.  I have certainly learned something!

Yes, the typical tagpoints for the trunk would be:
- When a release is made. Those tags should be called "yadayada-release"
or similar.
- When a branch is made. Those tags mark the root of the branch and
shoule be called "yadayada-root" or similar.
- When some other interesting point in time is needed to be marked -
typically before and after mergework. When you work with branches you
often want to tag before merging and when the merging is done. This is
mainly to facilitate further mergework in the future. But of course -
since we will mostly be merging in one direction from the branches into
the trunk such tags are mostly important on the branch.

regards, Göran