Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.It is kind of annoying that the project maintainer has to put in this link, since project* has enough information to generate this automatically, in many cases (ie. the cvs directory and the viewcvs URL from the repository setup form).
However, there are some caveats:
- ViewCVS is really old, and AFAIK no longer officially supported. The new project is ViewVC, which as I understand it works better with other version control systems. I have never used ViewCVS, only ViewVC, and I'm not sure if the two programs work in the same way or not with respect to how we would generate URLs for the repository.
- CVS and SVN handle tags and branches differently. So if we were to automatically generate a URL for the repository, I think we would want to think about where we would have the url point to. For CVS this might not be a problem, since tags and branches aren't really a separate location, but on SVN there are different directories for trunk, tags, and branches. Since ViewVC works well with subversion repositories, and since I'm using subversion on the site I'm building, I care about this more than others might.
- Some sites might provide CVS or SVN hosting, but may be fine with users hosting their project on their own repository or some other location. So I think we want to make it possible for a project maintainer to edit this link directly.
I'm not sure what the best way is to get around these issues. For the case of d.o, the solution might not be that complicated. However, I think we should try to stop putting code in project* that is d.o specific--there's already quite a lot of it, and it makes it tricky for people to use on non d.o sites. Furthermore, since I'm using this on my site, I have less interest in writing a d.o specific patch and instead would plan on making this more generally applicable to other sites as well.
So, any ideas on the best way to do this?
AC
| Comment | File | Size | Author |
|---|---|---|---|
| #24 | 156118-auto_repo_viewer_link-24.patch | 899 bytes | mikey_p |
| #23 | 156118-auto_repo_viewer_link-23.patch | 2.46 KB | mikey_p |
| #8 | cvslog.repo-link-default.8.patch | 1.04 KB | sun |
Comments
Comment #1
dwwa) no need to hard-code for a specific VC viewer. there should just be a setting.
b) cvs.module already has such a setting, so that the auto-generated links in the CVS log viewing stuff works (e.g. the links to diffs, etc).
c) this really should be in cvs.module (or, more correctly, the vc_project.module once jpetso is done), not in project. cvs.module should just extend the project node and add the cvs-specific stuff, instead of having project* do conditional checks for what vc-related module(s) is/are enabled.
d) i agree we could still allow people to edit it, but just have it default to the auto-generated link.
e) perhaps we could even re-use the existing settings in cvs.module for interfacing with the viewer? if not, we should just add another similar setting to the same form that works the same way.
f) needless to say, not every project is integrated with a cvs directory, so we should only generate this link if it's configured as such (just like the cvs access tab, etc, etc). whatever we do should be wrapped in that same helper function we recently added. ;) and, eventually, not every project on the site will be integrated with the same VC system. i could imagine sites hosting lots of projects where some are in CVS, others SVN, others git, etc. project* shouldn't care. that's up to the VC-specific backends to the vc_api.module to worry about...
g) d.o-specific code has no place in project*. i've been trying hard to erradicate it, whenever possible. i'll probably be creating a drupalorg.module in contrib in the near future to start explicitly moving any remaining d.o-specific stuff into. you have my full support for avoiding d.o-specific hacks. at long last, there's becoming a critical mass of project* users (jquery.com, you, me, etc) that aren't d.o. let's keep it that way, and keep expanding that user community to get more folks involved in development.
thanks,
-derek
Comment #2
aclight commentedI'm not quite sure how to go about creating the UI for doing this.
I've added 2 new fields to the {cvs_repositories} table:
webrootstores the base URL for the web based repository browsing (eg. ViewCVS)webroot_overridedetermines whether project maintainers can override the value for CVS tree that will automatically be created from the webroot and the project's repository directory and shortnameI've added these two settings into cvs_repository_form under their own fieldset called
cvs_browser.Assuming this sounds good so far, how should we handle this in the project_project edit form?
For new projects, we need to know the repository, directory, and shortname first before we can create the cvstree value. Should we even have the setting on the form for a new project? Should we show the user the automatically created value after they submit the project form (sort of like what happens with project_release nodes)?
For projects that are being edited, we can of course have cvstree filled out. But what if the user changes the repository, directory, or shortname? Do we recalculate cvstree? How do we keep from overwriting a value the user has manually entered and maybe doesn't want changed?
Because most of these changes will go into cvs.module, and since I'm already using a forked version of cvs.module, creating patches is a pain. So I'll hold off on writing too much for this until we agree on how this should be handled in the first place.
AC
Comment #3
gábor hojtsyI am all for autogenerating this link. I did go in and added such missing links to some projects, so next time I did not need to guess ;)
Comment #4
sunSee also #435528: Display link to drupalcode.org repository for "Browse the CVS repository" by default (drupalorg module)
Comment #5
sunAforementioned issue contains a patch specific to drupal.org now.
Comment #6
marvil07 commentedI think this is related with versioncontrol issue: #354509: Make repository URL backends pluggable
Comment #7
dwwAs I mentioned in #1.C, this should be fixed in cvs.module, not project (nor drupalorg). About to mark #435528: Display link to drupalcode.org repository for "Browse the CVS repository" by default duplicate with this.
Comment #8
sun@dww: My point in the other issue was that this default is specific to drupal.org. I'm not sure whether it really makes sense for every site in the wild using project/cvslog. Additionally, it would be quite a challenge to make this user- or admin-configurable, as that would involve to fiddle with quite ugly token replacement, and finding a usable UX at the right location to make it configurable in the first place.
So in essence, I heavily disagree with this decision, as the other patch is ready and was a 5 minute job to get completely right. The functionality cannot be added as is to cvslog, because it would have to be configurable, so it works for all users of the module, not only drupal.org. But for this patch, I don't care and didn't even think about other installations, and I don't see a feature request unrelated to drupal.org by other users, so effectively we are talking about adding a configurable feature to cvslog module that no one asked for. We badly need this on drupal.org only.
Comment #9
avpadernoComment #10
dww@sun: It's easy to add this as a configuration option when you're configuring the CVS repositories. We already have settings like this for making the diff links on pages like http://drupal.org/cvs?commit=422328 work. We just need another a similar setting for this feature.
It does make sense for anyone running project with cvslog that if cvslog knows about a CVS repository for a project that it could fill in this link automatically. It's stupid legacy code from ~8 years ago that has a custom field in project.module for this. I want to rip that field out of project.module and having this just done automatically by cvs.module makes sense. And of course, it'll be handled by versioncontrol API when we kill cvs.module. My main point is that I want to try to completely remove any hard-coded CVS special-cases in either project* or drupalorg to make it easier to move to Git, not add more of them.
I'm sorry I only saw your efforts in the other issue yesterday and how long you've been trying to get this done. I understand it's frustrating. But it's always a balance between getting things done quickly and getting them done right.
Thanks,
-Derek
Comment #11
dwwYeah, screw it. Let's solve this for real in versioncontrol_project and let's hack it for now on d.o. I reopened #435528.
Comment #12
marvil07 commentedUntil now the way to show logs on vcs api lives on main versioncontrol module, so I am marking this as duplicate in favour of #156118: Automatically generate the value of 'Link to webcvs/viewcvs' field for a project and #354509: Make repository URL backends pluggable
Comment #13
marvil07 commentedforgot to change the project
Comment #14
dwwI'm confused. In #12 this was marked duplicate with itself...
Comment #15
marvil07 commentedRe #14: You are completely right, blame on me :-p
I tried to mean #976148: Recover links to VCS web viewers and issue tracker at views.
Comment #16
dwwSorry, I finally got around to reading what marvil07 is talking about in the linked issues. You misunderstand what this issue is for. We're not talking about commit logs. We're talking about the "Browse the CVS repository" link in the "Development" block on project nodes, e.g. at http://drupal.org/project/project -- if vc_project knows what repo your project is connected to, and VCAPI knows about web viewers, we should be able to generate those links automatically. Which needs to happen. Outside of views. See what I mean? ;)
Comment #17
sdboyer commentedAh yeah - it's a related problem (they'll both rely on the same basic interface in VCAPI), but this'll access it directly, not pass through views.
Comment #18
sdboyer commentedThis'll be really simple to do...once we implement #354509: Make repository URL backends pluggable, which is at the tippy-top of the sprint 8 priority list.
Comment #19
marvil07 commentedHope to post something here after #354509: Make repository URL backends pluggable is fixed.
Comment #20
marvil07 commentedI do not really see the "Development block" at the code, so, now that #354509: Make repository URL backends pluggable is committed, I can provide the ay to get that URL:
:-)
Un-assigning for now, I think the block itself is going to be easier to implement for this module maintainers, if not I can take it again.
Comment #21
mikey_p commentedThis may be better off against drupalorg module where this is currently handled, but I'll try to take a look at this today.
Comment #22
dwwI'd rather we did it in vc_project than drupalorg if possible. Thanks!
Comment #23
mikey_p commentedHere's an auto version that uses a sitewide setting from versioncontrol_project for the base_url. This is working well for me locally in combination with #1026110: Add URL plugin for git.drupal.org customizations.
Comment #24
mikey_p commentedI decided to remove the setting and let this just pull from $repo->data['base_url'] so if that's not set this won't work, otherwise, this works great.
I'm going to go ahead and commit the attached patch.
Comment #25
dww#24 assumes every project has a repo. Seems like we need to wrap that in a
if (!empty($node->versioncontrol_project['repo']))...Comment #26
mikey_p commentedThanks, I committed a small followup.