Filing in via DVS will also remove methods? if so, I need to start using
it for my packages. Are you going to create an SMDVSInstaller?

About the Manager - are you aware that you have very few class comments?
well usually your code is very clear and the intentions are obvious, but
I didn't get the Manager, and the division of labor between it, the
package, the dumper, and the packagePanel GUI. 

Could you elaborate on this?

Daniel

Avi Bryant <avi at beta4.com> wrote:
> 
> 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