How to merge only changes of certain files of a given changeset into a working copy?
Sean Russell
ser at germane-software.com
Fri Feb 27 06:31:36 CST 2009
Shridhar Daithankar wrote:
> On Friday 27 February 2009 15:43:32 Marko Käning wrote:
>
>> What if I want to merge only changes of a certain file (and not the whole
>> directory or repository containg all files) in a given changeset into my
>> current working copy?
>>
> Merge the changeset and revert the files you don't want.
This really is the best way to handle this. If users are using the SCM
correctly (and there's *always* a "correctly," for any SCM), then they
should only be checking in related changes together. A change set
*should* be considered a contextual unit; if any ClearCase person argues
with you about this -- and they inevitably will -- then ask them why
they think any modern database that doesn't support atomicity is acceptable.
Incidentally, this issue is why block-level commits (a-la the
darcserific HG "record" extension) is so very important. If you've been
very good and have been working on exactly one thing, "hg ci" is
perfectly sufficient. If you've been wandering a bit in different
files, then "hg ci <file> <file>" -- a little more tedious -- is
adequate (and there really isn't a much easier solution). However, if
you're the sort of developer who fixes small bugs as s/he encounters
them (my favorite example: correcting API comments, possibly unrelated
to the task you're working, on as you go), or if you're used to Darcs,
then "hg record" is a life saver.
The point is that change sets are transactions; there's context in a
commit in Subversion or Mercurial (or Darcs, or any *sane* VCS). Even
if you check in multiple files in ClearCase at the same time, they're
really separate check-ins, and the only thing that associates them with
each other is the time stamp, which is a horrible, horrible way of
associating things like this. This is the one thing that absolutely
kills ClearCase for me; even Rational knows this -- it is one of the
reasons why they wrote the UCM layer and added "activities," which is a
horrible implementation of what could have been a really nice feature.
>> I wonder whether I run into a conceptual problem here, typical for
>> file-versioned SCM's like CVS or CC, or whether there is indeed a standard
>> way to merge only singular files in hg.
>>
> Conceptually it is a problem. If a changeset adds a function in C++
> header/sources, merging only the header will yield a non-compilable source
> tree.
>
Exactly. ClearCase's fundamental design assumes that files are utterly
unrelated to one another, and that changes to multiple files are
contextually disassociated. This is not only wrong, it results in a
broken SCM.
Finally, if ClearCase users want to emulate ClearCase behavior with
Mercurial, then a simple alias will do:
alias hgci='for x in `hg stat -mar`; do; hg ci $x; done'
Then they get per-file commit messages, and every file is checked in
independently, just as ClearCase does it. And if they're ClearCase
users, they're used to writing scripts, because ClearCase is unusable
without an additional layer of scripts and aliases to work around the
inconsistent and verbose command set.
IME, people who like ClearCase fall into one of two categories:
1. people who don't know any better; they either have never used any
other SCM, or only ones that were worse than ClearCase (CVS or
Visual Source Safe)
2. Rational consultants and ClearCase admins, who -- as long as there
are companies deploying ClearCase -- have guaranteed employment,
because administrating ClearCase is a full-time job.
I didn't intend this to wander into a rant about ClearCase, so to bring
it back on-topic: ClearCase is broken by design because it doesn't
support atomicity at the change set level; Mercurial is not, because it
does.
--- SER
> '
> OTOH that will demonstrate by example, why changeset based approach is better
> than tracking individual files :)
>
> HTH
>
More information about the Mercurial
mailing list