Bill Shannon wrote:
Stephen Lau wrote:
On Tue, Oct 24, 2006 at 06:41:42PM -0700, Bill Shannon wrote:
I think of hg commit as equivalent to sccs delget.
You need to significantly revise this thought :)
Why?
Because they're completely non-equivalent. :)
sccs delget adds one delta to one file.
No it doesn't. sccs delget adds one delta to all the files you specify.
hg commit commits a changeset to a whole series of files.
if anything, hg commit is more akin to a putback.
No, because it doesn't allow you to collect together unrelated changes
into a single operation that exposes them to other developers.
Sure it does. Once they are committed - anyone can push or pull from
your repository.
What it doesn't do is push back up to a parent... which is how it
differs from putback.
There is no 1:1 clean mapping of delget/putback => commit/push.
I'm not so much trying to argue about which is "right" or "wrong".
I'm mostly pointing out that this is different, and to better support
our people and our processes it would be good if there were fewer
differences.
Certainly. A number of these differences, IMO, need to belong in
'wx', though,
since they can be quite specific to the way we choose to do things
rather than
generally useful... others might make sense in hg itself, or mq, or an
extension, etc.
Remember that there are other Sun people using Teamware, who aren't
using the other Solaris customizations like wx. We need to help them
as well.
And there are other non-Sun people (like the developers of Mercurial)
who are using and developing Mercurial who don't need the baggage of
Teamware transition aids polluting their tool.
If you think of it as polluting, then obviously you're going to reject
any such suggestion out of hand.
I think of it as enhancing Mercurial based on the years of experience
with a similar product, to make it more attractive to the tens of
thousands of Sun developers who we hope will be using it. How many
other products like Mercurial can count their user base with 5 digits,
from one company? I think making Mercurial more attractive to Sun
developers, and in particular Teamware users, will only make it more
successful.
Yes, there may be some things that are only of benefit to the thousands
of Teamware users. Maybe those don't belong in the base Mercurial
product. Maybe those are made available separately using Mercurial's
extensive customization and extensibility support. Nonetheless, I think
they should be done.
I'm not keen on putting them into the base Mercurial product, since it's
not something that would enhance Mercurial to non-Sun/non-Teamware
users. I do like your idea to put it into an extension though...
perhaps a Mercurial extension that adds more Teamware-friendliness would
be useful.
If you are proposing a fork of Mercurial, then... well that's a whole
different argument.
That's absolutely not what I'm proposing.
Okay good :-)
cheers,
steve
--
stephen lau // [EMAIL PROTECTED] | 650.786.0845 | http://whacked.net
opensolaris // solaris kernel development
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
