How to merge only changes of certain files of a given changeset into a working copy?

[Shridhar Daithankar]

On Friday 27 February 2009 17:27:23 Marko Käning wrote:
> > Merge the changeset and revert the files you don't want.
>
> that's quite a hassle, indeed...

:) thats a relative opinion. Its only one command.

> > OTOH that will demonstrate by example, why changeset based approach is
> > better than tracking individual files :)
>
> Yeah, well, that's a point you might argue with ClearCase guys for
> hours... They are so used to their spec-files that's hard to beat! I guess
> the equivilant to that must be a local clone or branch, but still - am
> afraid there is no way to reflect this in hg...

Umm. You could use one clone of the complete repo. for one tool and futher 
branch/tag it for that tool only.

The disk space sharing between these tool clones, should prevent much of the 
disk wastage.

Of course restricting changes to the given tool in the given clone is matter 
of policy instead of a SCM provided lock now. 

It could be considered as a fatal draw back in some situations. I think it can 
be locked in sufficiently, by means of hooks and access control.

> So, I guess to achieve a scenario like the following:
>
>  /repo/tool1
>  /repo/tool2
>  /tepo/tool3
>
> where you want to merge only changes related to tool1, you would have to
> organize it in seperate repos:
>
>  /repo1/tool1
>  /repo2/tool2
>  /repo3/tool3
>
> Every tool gets its own repo and you are fine, since an update to one tool
> doesn't affect the other two.

Your proposal is also a good alternative, to which I would like to add the use 
of forest extension. But it has some limitations, I think e.g not all commands 
are reflected for forest use. (I miss fcommit  :( ).

But it is more hassle to set up compared to the scenario above.

> A concenptual thing, that's what it really is.

<rant>
I don't think so. IMO Its a limitation of cramming unrelated projects under 
single repository tree because thats the only configuration their file based 
vcs support(One cvs server, one cvs tree). 

Then it follows into checking out partial trees, maintaining a convoluted spec 
file, lost tags on files, incomplete branches, checkouts not being 
reliable/reproducible etc. etc. I don't know about clearcase but this holds 
quite true for CVS at least.

Sadly many people don't realize which part are features of the SCM and which 
aren bugs/limitations. Even given an alternative, many aren't willing to 
switch out of habit.  DVCS is too liberalizing for them.
</rant>

-- 
 Shridhar