Review of a new extension (hg remap) that I am working on

[Martin Geisler]

Jason Harris <jason at jasonfharris.com> writes:

I'm putting this back on the list -- please send followup there as well.

> On Jun 15, 2010, at 3:57 PM, Didly Bom wrote:
>
>> On Tue, Jun 15, 2010 at 2:16 PM, Jason Harris
>> <jason at jasonfharris.com> wrote: How about having a root .hgperclude
>> file which contains a list of paths. (or maybe hgdesanctify)
>> 
>> For these paths in hgperclude any local commits to the file would be
>> especially recorded. Ie there would be the blessed version recorded
>> and the local revision recorded. Any outgoing / push to the server
>> would never push these changes, it would only push the blessed
>> version. Also any incoming / pull would never see anything but the
>> blessed changes in a repository. Ie the revision pushed / pulled
>> would be sort of the "hg cat -r lastBlessedVersion
>> path/in/hgperclude"
>> 
>> Then if you wanted you would have 'hg preclude <paths>' and 'hg
>> unpreclude <paths>' would change the contents of the .hgpreclude
>> file. You could even have 'commit --unpreclude paths' would do a one
>> off commit of these files and bring the blessed revision up to the
>> current local revision
>> 
>> That way the project administrator would every so often do a 'commit
>> --unpreclude theproject/compilersettings.c' or something... then
>> everyone pulls this file, merges it like normal, etc.
>> 
>> Would this work?
>> 
>> Cheers, Jas
>> 
>> Jas,
>> 
>> the original purpose of the remap extension is to be able to have
>> files (or folders) which are warranted to be present on the
>> repository after any update operation, but which are not version
>> controlled and thus keep their contents after you switch to a
>> different revision (using update). They could also propagate
>> automatically when cloning.
>> 
>> Initially, I thought of this as a one way operation (from source to
>> target files) but I think that having a command to go from target to
>> sources would be a good idea.
>> 
>> On top of that basic premise, maybe you could achieve what you want
>> by using a versioned mercurial queue, where you could store your
>> local changes (over the source files)?
>
> Hmmm... Wouldn't queues would be hard for novices in a team to use?
>
> I would envisage something simple for the project leader to set up and
> then dead simple for the people in the team to use. Thus having a sort
> of meta level where you need to opt in to propagate the changes you
> have made locally seems like the right thing to do... Otherwise all
> the normal Mercurial machinery just works...
>
> Cheers, Jas

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/mercurial/