Bill Shannon wrote:
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.
I think I agree here, I believe this is something that could be done
with a local hook.
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.
This could also be done with a hook (in the parent).
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.
I split both ways than this. Doing things ON's way, there's
absolutely no difference, doing things the way described above there
clearly is. (though I think one comment could do for both, either way).
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?
The intent as I recall it was a keyword format matching that of
Subversion (I honestly forget if any agreement was reached on this *at
all*). The barriers that got in the way relate to appropriate places
to hook this into mercurial (in short, there don't seem to be any that
are ideal).
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.
The version of your file is the version of the workspace at that point
in time. I think we're talking about different things here. Steve is
talking about the SCCS %I% expansion, whereas you seem to mean
possessing a version in general.
For all intents and purposes the changeset that last modified a file is
that file's version. The changeset ID is guaranteed to be accurate, in
the face of merges, and people pulling things into workspaces in
different orders, the revision number may change (in other words, it's
only canonical when used as a reference point within the same workspace).
-- Rich
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
