Code management system
s-ramesh at mailAndNews.com
Thu Mar 9 19:53:45 UTC 2000
I liked both the Envy (the later versions where they toned down their
ownership model) and Team/V, but found I preferred Team/V over all. It was
simpler and more light weight with an optimistic check-in implementation.
It was a lot easier to customize for your project. Both had relatively poor
versioning for non-code objects - you could see it was added as an
afterthought. This would be something to put in from the beginning.
One thing that I added to both was a control file that specified all
components (both code and other files) that was in ascii and could be
easily scanned to see if there was a versioning problem. This was also the
file used to recreate any particular version from the repositories.
The other thing to think about for version control apps is crash recovery.
With its constant server interaction, Envy did have the best crash recovery
mechanism, while Team/V's was primitive at best. Combining Team/V's
lightweight versioning with a more robust crash recovery mechanism could be
the best of both worlds.
At 09:06 AM 3/9/00 -0800, Ranjan Bagchi wrote:
>--- Stephen Pair <spair at advantive.com> wrote:
>> > Ranjan Bagchi wrote:
>> > > The thing which I liked the most about the ENVY
>> > > environment is that they'd done a really robust
>> > > analysis of code management (Editions, Versions,
>> > They've done a _terrible_ analysis of code
>> > Why do you need applications, subapplications and
>> > maps, for example? They should all be a single
>> concept -- recursive,
>> > conditional inclusion.
>> > And their miserable, in your face, ownership
>> design, which positively
>> > encourages swapping user identities as you
>> > -dms
>> Any system in Squeak should also consider object
>> versioning in general (not
>> just source code). You will probably want to
>> version those Fabrik
>> constructions (and there may not be any source code
>> to go with them). Also,
>> it should play nice with ImageSegments and
>> name-spaces...maybe one or both
>> of these should be the basic unit for versioning.
>> I would also eliminate multi-user support from the
>> scope of the initial
>> iteration and focus just on the versioning issue.
>> ...oh yeah, and multiple
>> versions of things should be able to coexist (and
>> work) in one image.
>> - Stephen
>Well -- I liked using Envy. I was even happy to see
>it in VA Java.
>I don't really agree that Envy was that awful seeing
>as I found it really invaluable to trace back every
>method accept and know which method version were
>attached to each class. It certainly did have a steep
>learning curve to it and when the group I was with
>went from just filing out class-categories to Envy it
>took us over a month to get really comfortable.
>The point I was trying to make, though, is that it was
>nice to have the deployment-components and versions
>abstracted out as first class objects, so a class
>could identify which "package version" it came with..
>if it were necessary.
>I'd think that we should certainly include multiple
>users in a design and plan, but yeah: it doesn't add
>as much initial value as a robust component and
>versioning system. It would be nice to design the
>plan, though, so that if someone were interested in
>taking it in that direction a roadmap existed.
>Do You Yahoo!?
>Talk to your friends online with Yahoo! Messenger.
More information about the Squeak-dev