Is there a Mercurial extension like svn propset?

Question

I need to bind custom metadata to source files that are tracked through Mercurial. The svn properties commands are exactly what I need.

Is there a mercury extension that provides commands similar to propset , propget , propdel , etc.

If there is no extension, why not?
Is there an alternative / better approach for custom metadata when using Mercurial?
Are custom metadata not useful to anyone else?
Is the extension very desirable but not yet written?

Additional information: If this helps. The metadata I'm tracking is whether each file was code, unittested, qa'd, etc. This data should be traceable, and merging between branches / clones is not good enough.

Answer 1

The mercurial philosophy is that you track files and only files. You cannot even check an empty folder because Mercurial does not know about folders!

So here are the answers:

• I can not find an extension that does what you want. (You can write yours, of course.)

• A mercurial way to do what you need is to store the data in a flat file and use some scripts to process it. :(

It looks like you have a well-designed system in place and good engineering practice in your company, so I will not be pedantic here, but you can make a reasonable argument that your method does nothing but portability. There is nothing magical about properties, I would just run svn proplist -v . on your tree, dump that for hidden files - something like .tracking - just explicitly merge it together with your normal files. This really doesn't add any work, since you should still combine properties.

I hope this works for you!

Answer 2

The Mercurial convention is to put the .hg* file name in the root of the repository and use them as dictionaries (of some kind) to map file names to property values. For example, instead of svn:eol-style the hgeol extension uses a file . Hgeol .

In case of viewing the tracking code, I would recommend writing another extension that allows you to manipulate this metadata and have this extension, saving its state in a format other than merging.

Answer 3

I am going to add a really late quasi-answer to this question, as many, many people using Mercurial, including me, ask for something that we want to have, and expect that after using other tools, such as properties svn.

As far as I can tell, there is no such extension for Mercurial. till.

Yes, the Mercurial method seems to be designed to track files and only files. And it may be that they come up with such an extension to put the necessary metadata in files ... repo / .hg *.

OK I played with that. Do things manually before trying to write tools.

The key disadvantage of approaching files with the .hg version is that if you look at a version other than the tip, for example, "hg update -r OLD-VERSION", you get the old version of the metadata.

I think the key point may be to include metadata in files ... repo / .hg *.

But ... most operations should be performed with or after the latest version of such files. That is, I think that such metadata files are "superior" to the version, i.e. They want to be versions, but in an ideal situation, you can think of them as superimposed on files with a normal version, which you might have checked for an older version.

In addition, in many cases, you want the forking of such metadata files to be handled separately. For example. imagine a file in which you are trying to write a description of all the branches together. Perhaps a comparison of branches such as "branch1.1 is a newer version of branch1". You do not want this description to be in any branch; or rather, you want it to be on both branches at the same time, and you want the changes to reflect on both branches.

Such an alleged extension will either work on "hg cat -r tip ... repo / .hg-my-new-metadata". Or, he will somehow overlay the version of the files with the metadata files with the normal version.

I made some progress on this using subrepos:

 superrepo files // normally-versioned-files <-- a subrepo metadata // version transcending metadata <-- a subrepo 

this allows me to check the latest metadata along with an older version of the files

This is not entirely true, because checking a specific version in a super-repository can get older versions of sub-reports of metadata. But at least the newer versions are in backbone.

Let me also note that if you put metadata in a neighboring subreport or save it in the same repo (but work at the tip), there is a problem you can do

 hg clone -r OLD-REVISION repo newrepo 

This will delete the metadata later than OLD-REVISION. Including metadata, which states that "OLD-REVISION passed all tests", that is, it will strip the metadata from a later version that can be applied to OLD-REVISION.

The same problem occurs with hg tags.

You could say “well, never do this” - never make a story. Unfortunately, this is often recommended as a way to tidy up the repository.

It seems hard to avoid this with Mercurial.