On Tue, Dec 19, 2006 at 10:31:39AM +0000, Darren Moffat wrote:
> Will Fiveash wrote:
> >+1 for me too.  wx has a number of problems and a strong Teamware/SCCS
> >bias so the above makes sense.  The thing I worry about is losing
> >functionality like:
> 
> Glad to hear that from someone who has done so much really cool work on wx!

Thanks.

> >- efficient and simple backup and restore
> 
> That should be a trivial hg extension.
> 
> >- gate rules enforcement.  I'm not just talking about pbchk but things
> >  like 'wx create' actually checked the parent's deleted_files to see if
> >  a file of the same name existed and warned the user about the
> >  conflict.  If the Mercurial way is to test for this at putback time
> >  it's too late.
> 
> That particular example doesn't actually make sense because 
> deleted_files won't exist in repository after we transition the master 
> gate to Mercurial.
> 
> IIRC that is actually only needed because of limiations in Teamware that 
> surface in this area and things like cyclic rename.  Mercurial best I 
> can tell doesn't suffer from those problems.

As long as the Mercurial tools make it impossible (or at least
difficult) for a user to do bad things in their workspace and break the
gate upon putback/push then a wx-like interface isn't needed.  If that
is not the case then some thought should be given this issue because
placing the burden on the developer to remember the various do's and
don'ts is asking for trouble.

> >- efficient determination of workspace changes
> 
> hg status -mard

I was hoping that was the case.

> >- efficient webrev creation
> 
> I have a draft of webrev changes for Mercurial, I need to merge them 
> with the recent updates that Dan did.
> 
> Please define efficient though.

"wx webrev"  8^)

Meaning, one can generated a webrev quickly and have it accurately
include all relevant workspace change.  I see from an earlier post
that you're working on making webrev Mercurial aware which is great.
I assume that the new webrev will provide "wx webrev" functionality in a
Mercurial workspace.

> >While I'm sure folks can concoct ways of doing the above if not already
> >supported by Mercurial it would be good if standardized ways of doing
> >the above were provided (be it tools or extensions, etc...).
> 
> That is what we are doing, trying to model as much as we can as 
> extensions, not just as hooks at push/pull time.

I'm not familiar with Mercurial so I don't know about it's capabilities
in this area but my concern is that the fundamental shortcomings in the
Teamware/SCCS/ON dev. world are addressed in the Mercurial world.  If
these issues can be dealt with transparently via extensions and hooks
that sounds like an improvement over wx.

BTW, is there a doc that shows a mapping of wx functions to Mercurial
tools?

-- 
Will Fiveash
Sun Microsystems Inc.
Austin, TX, USA (TZ=CST6CDT)
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org

Reply via email to