Stephen Lau wrote:
Bill Shannon wrote:
hg push will put back committed changes even though there are other
changes in progress (i.e., files "checked out")
This makes sense to me. If you haven't committed your changes in
progress, why would you want them pushed?
I wouldn't. But with Teamware, the putback would be blocked,
preventing me from putting back something that was half complete.
hg push doesn't "sccs get" / "hg update" the parent.
This also makes sense to me. What if the parent was in the middle of a
compilation when a push happened? You don't want things to be changed
from beneath you.
Again, compared to Teamware, this is confusing. If I do a push and then
look at the files in the parent repository directly, I don't see my
changes. If things were in the middle of being changed, Teamware would
prevent you from doing the push/putback.
There's no way to supply putback comments.
This also makes sense. Teamware allowed this because SCCS delta
comments were at the file level. With a changeset model, why would the
putback comment be different from the changeset comment?
It depends on how you work.
SCCS comments are stored at the file level, but I can check in a bunch of
files with one comment. I usually check in files with comments that tell
exactly what changed in each file. The putback comments describe the
larger goal of that collection of file level changes.
No support for SCCS keywords, or anything like them, in files.
This is something we're working on. Rich Lowe and I (and possibly
others) took passes are keyword filtering, though Rich did more recent
work - my attempt was a long time ago. We both hit roadblocks though;
and I set my attempt aside to work on more pressing matters.
What are you hoping to accomplish?
No version numbers for files, only unreadable changeset ids.
This has been a matter of debate. I personally don't see the value in
embedding version numbers in files. If you really need them to identify
a file, the changeset id, or revision number (if you want a
monotonically increasing number - though this is not canonical and may
vary depending on your repository) should be sufficient.
If I have two copies of the same file, outside the repository (e.g., on paper),
some kind of version number gives me some hope of telling which one is newer.
Yes, there are lots of other ways to do this. But after working with files
that have version numbers for 30 years, I'd kind of like to have something
like that for the next 30 years.
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
