Need view for individual commit message

See also #780342: Handle linkrot from CVS commit browser. I think we need this ASAP, but it's not technically a launch blocker, so I'm going to call it sprint 9...

One big question here is whether we should ever expose the vc_op_id in this way. Now that all projects reside in their own repositories, that number is even more artificial than it was before - and unnecessary, since commits can be referred to by their SHA. My strong preference would be to use the SHA; it's a real piece of data that can be determined without looking at d.o at all, rather than being the product of random autoinc. Also because the views, as we've designed them right now, use the SHA, not the autoinc id, to identify commits in the commitlog.

First step, let view know how to filter by the commit. Now, maybe on #780342: Handle linkrot from CVS commit browser redirect to the right URL?

I don't care if it's op_id or hash. SHA sounds good for a variety of reasons. We just need something to link to. And yeah, over at #780342 we'll deal with redirecting.

I think vc_op_id is ok for versioncontrol, if we use revision, we need to do it at versioncontrol_git, that have unique revisions per operation(for example cvs and svn do not have)

re: #5 - I've thought about this, actually. Only non-atomic systems (SVN is for sure atomic, it does have unique rev numbers) don't have a unique rev id of their own, and that's only CVS. There's no reason the generic can't implement the much-more-helpful revision id, and the CVS backend (if a new one ever gets written) overrides it and uses vc_op_id. That's one of the beauties of this system - the generic doesn't always _have_ to be the lowest common denominator.

Re #6: Not sure, an overwritten views set for git using revision instead of vc_op_id seems like the better idea to me.

@marvil07: if cvs is the only one that needs vc_op_id, and using the vc_op_revision is better in the general case (which it sounds like it is), I vote for sam's approach. No sense overly complicating this. Just because we have pluggable views sets doesn't mean we need to use them for everything. ;)

I'm not sure the hidden exposed filter is necessary. I still vote for an optional argument using revision, and vc_cvs can do otherwise. But, it really doesn't matter that much to me.

I am working on this to include repository as first argument.

We can not be sure that different repositories would have different revisions. For git(and other VCs that use hashes) is mostly improbable, but other VCS that have numeric identifiers would not have that, so filter by repository is needed.

Here the patch, it:

• Add an argument for filter by repository in the individual_commit_view.
• Modify the link shown on operation date handler.

I agree that vc_project could offer a view based on this one that use project->uri instead of repo_id.

But please note that the reason for having this in is:

We can not be sure that different repositories would have different revisions.

, I mean VCSs that do not use hashes are too prone to have too many duplicates and that's enough reason for me to have this in.

Please remember that we are trying to build a reusable system, if we end up too d.o specific we are losing a lot of help/feedback from community.

I read http://warpspire.com/posts/url-design/ recently, and it really struck a chord. Happens to be from githubbers, but that's really incidental here, it could be from anyone with a heavily data-driven website.

Really, my preference is for more, _real_ information in the URI as possible. We can't use repository name, as that's not guaranteed to be unique anymore (correctly), but we could use the uri from vc_project, as you've both pointed out. For the final view that's presented, I'd like to have the uri & the blob, as they're the real, user-facing data.

We're increasingly getting into a position where the views provided directly by commitlog are a liability. I'm thinking we want a way to selectively disable them, so that commitlog can be enabled but not all of its views (sets) are given menu entries. Sounds like a feature to be added to views sets.

So, does it mean RTBC?

Sorry. Yes, RTBC.

Ok, patch committed.

Now we need another issue for doing the project uri relation on vc_project.

Created related issue at #1040140: Create a view for individual_commit view_set that use $project->uri instead of repo_id