Re: commit: CVSROOT cfg_local.pm
Michael Rubinsky <[email protected]>
| Newsgroups | gmane.comp.horde.cvs |
|---|---|
| Message-ID | <[email protected]> |
Quoting Michael M Slusarz <[email protected]>: > Quoting Chuck Hagenbuch <[email protected]>: > >> Quoting Michael M Slusarz <[email protected]>: >> >>> Log: >>> Looks like we might have to specify the repository name now >>> (caching issue? - >> >> You had the git repo remembered in the last repository preference. > > Ah.... yes. Didn't realize I was logged into dev.horde.org. Still, > we probably need this regardless in order to prevent issues like > this in the future. We actually had a fairly lengthy discussion about this on irc, we really should make changes to chora so that existing links don't break when any one using chora adds a second repository to their install... discussion attached below for posterity: mrubinsk 11:11:51 Fatal error: Uncaught exception 'VC_Exception' with message 'No revisions found' in /var/www/dev.horde.org/horde/framework/VC/VC/git.php cjh 11:12:09 ahhh cjh 11:12:18 you must be on one of the git repos cjh 11:12:31 we need to include the repository in the commit message links mrubinsk 11:12:32 eh? cjh 11:12:44 your error is coming from the git driver mrubinsk 11:12:58 oh, you mean since I previously was one a git page? mrubinsk 11:13:06 s/on/one cjh 11:13:14 yes mrubinsk 11:17:03 so, it's now no longer possible to just type in the URL directly for the page/directory you want to see in Chora if it's in a different repository then the one your currently viewing? mrubinsk 11:17:37 any chance on putting the repository into the url rewrite rules? cjh 11:17:47 sure cjh 11:17:57 i'd do something like /repository/-/<path> cjh 11:18:02 to separate the two mrubinsk 11:18:42 so c.h.o/repository/horde-git/framework for example? cjh 11:19:00 c.h.o/horde-git/-/framework mrubinsk 11:19:11 oh, a literal '-' cjh 11:19:16 yes :) mrubinsk 11:19:19 :) cjh 11:19:21 like the gdata category urls mrubinsk 11:19:43 gotcha mrubinsk 11:26:02 eh - except this will totally break all the current links that are floating around anywhere mrubinsk 11:38:42 cjh: do you want to me add the rt=horde parameters to the cfg_local.pm script? yunosh 11:40:10 hi, sorry if i jump in late, but we should make sure that the old links still work yunosh 11:40:18 without the repo, that is mrubinsk 11:41:19 I don't see how they CAN work if we don't specify the repo - and we are logged in and viewing a different repo - how else to force the change in repo? yunosh 11:42:09 maybe forcing the repo in the url if it's *not* the default repo? mrubinsk 11:43:17 then urls like /fobar/lib/file.php would break if there is also a repo named fobar, wouldn't it? mrubinsk 11:43:58 ah, would have to match the /fobar/-/ mrubinsk 11:45:30 so, if no repo parameter is found, assume it's the default - and do a better job of catching the exception - showing a better error message etc... mrubinsk 11:46:33 that would mean, of course, that if someone changes the default repository at any time, all the current urls would break mrubinsk 11:47:04 (talking in general here, not c.h.o specific) yunosh 11:47:27 yeah, but that's better than breaking them *without* changing the default repo mrubinsk 11:47:37 true yunosh 11:47:56 or maybe, as a last resort, we could add this as rewrite rule for c.h.o only mrubinsk 11:52:21 still need to catch the exception though in chora, even without the rewrite rule, right? If no rt parameter is passed, assume it's the default - or put up a user friendly error message yunosh 11:53:11 yeah cjh 11:54:18 maybe we can just turn off the remember last repository pref on c.h.o cjh 11:54:31 otherwise you're basically removing that feature anyway mrubinsk 11:54:32 oh, it's not as bad as I thought for our specific case, it's only an issue if your logged in. So, it's a pain in the butt, but at least it doesn't effect guest users mrubinsk 11:54:56 heh - or what cjh said :) cjh 11:55:09 in other words, i'm against the choice of assuming the default repository mrubinsk 11:55:31 that sounds like the best choice considering we'd be defeating the purpose of that pref mrubinsk 11:57:32 though that pref would be pointless for *any* group using chora with more than one repo mrubinsk 11:59:40 ...and turning it off wouldn't solve our issues, anyway, would it? i.e. how would we specify the repo without breaking current links if we don't make any assumptions? cjh 13:19:02 mrubinsk: cvs should still be the default repository cjh 13:19:07 the git links would have to include the repo cjh 13:19:13 and we'd need to leave cvs as the default mrubinsk 13:19:53 cjh: sorry, I thought you said you were against assuming the default repository? mrubinsk 13:20:27 or am I confusing something? cjh 13:21:20 i might be confused cjh 13:22:34 maybe the remember last repo preference should just go away cjh 13:23:11 i don't know if it's ever really expected behavior cjh 13:23:33 by default, chora root could show a top-level tree of repositories mrubinsk 13:23:48 yea, I think it would be more intuitive to either explicitly specify the repo, or assume the default cjh 13:23:52 and we could have a rewrite rule for c.h.o that would add the /horde-cvs/-/ to urls that don't have anything cjh 13:24:17 or that mrubinsk 13:25:36 or both :) cjh 13:33:12 sure -- Thanks Mike "Time just hates me, that's why it made me an adult." - Josh Joplin -- To unsubscribe, mail: [email protected]