Is there a Mercurial extension like svn propset?
Asked Answered
L

3

7

I need to attach custom metadata to my source files that at tracked via Mercurial. The svn properties commands are exactly what I need.

Is there a mercurial extension that provides commands similar to propset, propget, propdel, etc?

If there isn't an extension, why not?
Is there an alternative/better approach for custom metadata when using Mercurial?
Is custom metadata not useful to anyone else?
Is the extension dearly desired but just not written yet?

extra info: If it helps. The metadata I'm tracking is whether each file has been codereviewed, unittested, qa'd, etc. This data needs to be traceable and merges between branches/clones aren't fine grained enough.

Lardy answered 14/12, 2010 at 20:14 Comment(1)
Have you tried the mercurial mail-list? You might get some responses there as well. (Only some Mercurial devs are on SO, sadly not all. )Rowel
B
4

Mercurial's philosophy is that you track files and only files. You can't even check in an empty folder because Mercurial doesn't know about folders!

So, here are the answers:

  • I can't find any extension that does what you want. (You can write your own of course.)

  • The Mercurialful way to do what you want is to store the data in a flat file and use some scripts to process it. :(

It sounds like you've got a pretty well thought out system in place and good engineering practice at your company so I won't be pedantic here about it, but one can make a reasonable argument that your method does nothing except hurt portability. There's nothing magical about properties, I would just run an svn proplist -v . on your tree, dump that to hidden files -- something like .tracking -- just explicitly merge it along with your normal files. This doesn't really add any work since you have to merge properties anyway.

I hope that works for you!

Bennet answered 14/12, 2010 at 22:51 Comment(0)
G
4

The Mercurial convention is to put files name .hg* into 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 .hgeol file.

In case of tracking code review, I'd recommend to write another extension that allows manipulation of this metadata, and have that extension store its state in a merge-friendly format.

Gerfen answered 14/12, 2010 at 22:40 Comment(0)
B
4

Mercurial's philosophy is that you track files and only files. You can't even check in an empty folder because Mercurial doesn't know about folders!

So, here are the answers:

  • I can't find any extension that does what you want. (You can write your own of course.)

  • The Mercurialful way to do what you want is to store the data in a flat file and use some scripts to process it. :(

It sounds like you've got a pretty well thought out system in place and good engineering practice at your company so I won't be pedantic here about it, but one can make a reasonable argument that your method does nothing except hurt portability. There's nothing magical about properties, I would just run an svn proplist -v . on your tree, dump that to hidden files -- something like .tracking -- just explicitly merge it along with your normal files. This doesn't really add any work since you have to merge properties anyway.

I hope that works for you!

Bennet answered 14/12, 2010 at 22:51 Comment(0)
B
0

I'm going to add a really late quasi-answer to this question, since it is one that many, many, people using Mercurial, including me, ask - something we want to have, and expect to have, after using other tools like svn properties.

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

Yes, the Mercurial way seems to be to track files and only files. And it might be that they way to right such an extension is to put the necessary metadata into ...repo/.hg* files.

OK. I've been playing around with that. Doing stuff by hand, before trying to write tools.

The key weakness of the versioned .hg files approach is that if you check out a non-tip version, e.g. "hg update -r OLD-VERSION", you get an old version of the metadata.

I think the key thing, therefore, may be to put the metadata in ...repo/.hg* files.

But... most operations should be performed with or upon the latest version of such files. I.e. I think such metadata files "transcend" versions - i.e. they want to be versioned, but in an ideal situation you might imagine them as overlaid upon the normally versioned files that you may have checked out an older version of.

Moreover, in many cases you want the branching of such metadata files to be handled separately. E.g. imagine a file where you are trying to write a description of all branches, together. Perhaps comparing branches, like "branch1.1 is a more recent version of branch1". You don't want that description to be on either branch; or, rather, you want it to be on both brancges, at the same time, and you want changes to be reflected on both branches.

Such a putative extension would either operate on "hg cat -r tip ...repo/.hg-my-new-metadata". Or it would somehow overlay the versioned of the files with the normally version transcending metadata files.

I have made some progress on doing this with subrepos:

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

this allows me to check out the latest metadata alongside an older version of the files

It's not quite there, because checking out a particular version of the superrepo may get old versions of the metadata subrepo. But at least the newer versions are in the subrepo.

Let me also note that, whether you put the metadata in a neighboring subrepo, or keep it in the same repo (but operate on the tip), there is a problem that you can do

hg clone -r OLD-REVISION repo newrepo

This will strip out metadata later than OLD-REVISION. Including the metadata that says that "OLD-REVISION passed all of the tests", i.e. it will strip out metadata from a later revision that might apply to OLD-REVISION.

This same problem happens with hg tags.

One might say "well, never do that" - never strip out history. Unfortunately, that is often recommended as a way of "tidying up" the repository.

It seems hard to avoid this with Mercurial.

Beachcomber answered 26/7, 2012 at 23:42 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.