Thomas Haas <[EMAIL PROTECTED]> writes: [...]
> As mentioned in my initial posting I consider this a work-around. > However, if certs only exit for revisions (And not for files) it is > the way to go. Probably I'm misunderstand what you're trying to do. The closest I can get is that you want to say something about a specific version of a file in the context of a revision (perhaps more generally: a specific version of a file for a branch, or for a "release" indicated in some way). I wouldn't have thought it would be useful to mark a version of a file (actually as Nathaniel commented, the contents of the file, which doesn't include its name or anything) without connecting that to something else. And if the "something else" can be a revision, then you could use a revision cert. Overall I'm not sure why using a revision cert is a workaround rather than the right thing to use. For checking a release, you can look at the certs attached to the revision and make sure they're all there, for example. I could imagine you might want to attach a cert to a particular file (you might want to make "README" as a file that needs a specific kind of check before making a release). What used to be file certs don't seem right for that. Technically I imagine that would be possible, if files have a permanent identity as proposed by Nathaniel recently, it might be possible to expose that sufficiently to attach certs to them. File attrs could be done like that, I guess? On the other hand, you'd probably want them to be versionable, so that wouldn't work well. How about using file attributes for what you want, rather than certs? _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
