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