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

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

Rob Withers <rwi...@at...> wrote:
> gor...@bl... wrote:
> > rwi...@at... wrote:
> > > our process.  Do we want to complicate it further, 
> > > technically, by trying to tackle cvssupport?
> > 
> > Honestly, no! :-) But we can check it out later.
> 
> Whew.  That's good.  :)   My opinion is that we are much better off
> using a trust system and minimizing the technical barriers.  We all want
> to create the highest quality system we can.

I agree - I am just "playing along" since there are a few people worried
about these things.
But as you say - I also think that a trustsystem is quite enough - if we
can't trust each other then we shouldn't give each other commit
capability IMHO. :-)

> > > How far off are we to 3.2final?
> > 
> > No idea. ;-)
> 
> Me neither, but it feels like we are getting close.  What can I do to
> help cvsproj and sqcvs along?

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.

> > Since you tagged those on the line above I assume you still have those
> > revisions :-) so the "-r 3.2g" is actually unnecessary (but correct).
> 
> Note that this has been a hypothetical; I didn't actually tag the unix
> stuff as I feel that that is Lex's or Ian's perogative.  

I know! I was just "pretending along". :-)

> There could be a lot of branches off of the trunk, which could get
> unweildy with all of the Root-of-XXX.  I like John's approach of using a
> <major>.<minor>.<patch>.0 (i.e. 3.2.7.0), then branches could be
> <major>.<minor>.<patch>.<branch>...(<subbranch>)  (i.e. 3.2.7.1).  I
> suppose we could even tag a particular revision of a branch as the root
> of a subbranch, like 3.2.7.1.0, and the subbranch would be 3.2.7.1.1 and
> so on.

I still want branchtags to have a special prefix/suffix like "-branch"
and the branch root tags to have another special prefix/suffix like
"-root" or "Rootof-" or whatever. A CVS repository quickly gets a LOT of
tags so you want to have a good naming standard for them and be able to
see what tags are branch tags etc. This is advice coming directly from
Karl Fogel's CVS book btw.

> > There is also the command "rtag" that can tag stuff without having a
> > workingcopy but I never use that - I feel in more control with "tag".
> 
> I agree, especially given your discussion of verifying with cvs update.
> 
> > > to checkout the branch:
> > > 
> > > cvs checkout -r 3.2g-experimental-protected-memory
> > 
> > Yes, this would check out the tip of the branch. This will place a so
> > called "sticky tag" on your files in your workingcopy so that all
> > operations from now on happen on the branch. Quite convenient. 
> 
> I see.  Now you won't be affecting the trunk at all.

Right.

> > You can
> > also move an existing checked out trunk onto the branch by using:
> > cvs update -r 3.2g-experimental-protected-memory
> 
> hmmm.  I don't follow you here.  What exactly does this do?  Oh.  Are

I am saying that an update operation with a revision option will update
your workingcopy to the state of the tag.
In my example I had checked out the trunk and wanted suddenly to work on
the branch - so I updated my trunk over to the branch by giving update
the branch tag as an argument. This will make CVS update/patch only
those files that are different in the branch. The end result is the same
as if I had done a checkout of the branch.

> you saying that if I have done
> 
> cvs co -r 3.2g

That would check out the trunk but as it was when tagged with "3.2g" -
which is not a branch tag. You are still on the trunk but with a sticky
tag "3.2g". The effect is that you can't commit anything because you can
not change "history"! But that is a sidepoint.

> then I could do 
> 
> cvs up -r 3.2g-experimental-protected-memory

Sure, this would move the workingcopy over to the tip/head of the branch
- since the branch tag always refer to the tip of the branch (only
changing the files that needs to be changed).

> and my working copy will now be the latest in the branched tipped with
> 3.2g-experimental-protected-memory?

"branched tipped with 3.2g-experimental-protected-memory?" - I am not
following your english here.
But I think the answer is Yes - your workingcopy is now the latest in
the branch called "3.2g-experimental-protected-memory".

> > This would have the same result as the checkout but with much less IO.
> > And moving it back to the trunk is done by clearing the sticky tag:
> > 
> > cvs update -A
> 
> Will this take the latest from the trunk, or the root?

Right. All sticky tags are cleared so CVS will then take the latest on
the trunk - can also be referred to as HEAD (a pseudo-tag representing
the head of the trunk).

> > My impression is that LinCVS is a poor clone of WinCVS/MacCVS (which are
> > pretty good by now). TkCVS looks interesting and has more advanced
> > features.
> 
> Very nice - I am d/ling tkcvs as I write this.
> 
> thanks and cheers,
> Rob

No problem - keep hammering, hopefully other people not versant in CVS
will learn something too! :-)

regards, Göran