On Sat, 26 Oct 2002 danielv at netvision.net.il wrote:

> Actually, I'd want higher level operator than #version:
> What I'd want is a #makeRelease message that increments and files out.
> An #abandonTo: message that changes version, removes the module, and
> files in the old one. This is a dangerous message, because it loses
> everything you've done.

"removes the module" isn't necessary, of course.  Using DVS to file in an
old version will automatically revert any changes you've made since then.

> Then for packages managed using DVS, I could use SM to download the new
> version (not install), and do compareTo: the new one using DVS.
>
> As a maintainer of such a package, I would be able to easily review my
> changes (to make sure I hadn't left some self halt in there), make
> internal releases ready (separate from posting the to the net).

> One thing that would be nice is if the package knew whenever it's code
> was changed, it could automatically increment the version only when it's
> needed, and also, this would allow the package to handle someone editing
> an old version (forking).

The manager does get notified when the code changes (and the * shows up),
but the mechanism it currently uses is far from perfect.  There need to be
a lot more hooks for it to be able to catch every kind of change.

> Do you think this is good functionality for the base PackageInfo? or
> does it clash somehow?

Well, a lot of it is functionality that's already provided by CVS, for
those of us who use it.  So I definitely wouldn't put it in the base
class.  I recommend you add a ChangeSetPackageInfo or some such that is
geared towards managing changeset style versioning; if the protocol seems
good, maybe I'll write a corresponding CVSPackageInfo that uses OSProcess
(or sqcvs?) to do the same sorts of things.

Although actually I think this stuff is better done by the PackageManager
- it has more to do with the filing in and out process than with the
semantics of the package itself.

Avi