I hope this is the correct place to ask this- I’m wondering what the guidelines are for creating repositories. As in; single repository per user, per tool, or per collection of related scripts/tools?
Also, a standardised repository description format might help make browsing the repositories more manageable, something like language/app, general category like animation or modeling. This might not be as important once SS integration happens, or maybe the forum threads are a better starting point for finding useful repo’s.
[QUOTE=cptincognito;2156]I hope this is the correct place to ask this- I’m wondering what the guidelines are for creating repositories. As in; single repository per user, per tool, or per collection of related scripts/tools?[/quote]
However you want it. For example, I may have a repository for my personal scripts, smaller stuff. But if I have a larger tool- or a collaborative project- I would give it its own repositories. Try to split it up how you think makes sense, though I suspect what makes sense will change as you get experience working with DCVS.
Also, a standardised repository description format might help make browsing the repositories more manageable, something like language/app, general category like animation or modeling. This might not be as important once SS integration happens, or maybe the forum threads are a better starting point for finding useful repo’s.
There should be another category added for “Language”, that is a good idea. As for ‘general categories’, I just think info like that should be left to the description.
I’ll start working on some of these features today, if all goes well.
Edit: I’ve started work on allowing repo settings (description, who can push) to be modified, but it’s taking longer than expected, partly because of my long hiatus. I might not be able to work on this tomorrow (I’m probably taking a final), but I expect that change to be done by Wednesday.
[QUOTE=Rob Galanakis;2113]Changes repo settings (users who can push, etc.)[/quote]
This is now done.
[QUOTE=Rob Galanakis;2113]Access to static address for latest revision, though UI or elsewhere, instead of by-hand workaround (right now, you can replace the revision number with ‘tip’, so when giving someone a link, instead of “http://tech-artists.org/hg/tao_official/tao_function_library/file/[B]64f1a3bbf80b[/B]/fn_arrOps.ms” it should be “http://tech-artists.org/hg/tao_official/tao_function_library/file/[B]tip[/B]/fn_arrOps.ms”, which will be the latest revision)[/QUOTE]
I didn’t actually write the script for the web interface to the repositories. I could undoubtedly try editing it, but maybe it would be better to check if there’s a new version available first (I heard it got an overhaul for the latest Mercurial version).
[QUOTE=Rob Galanakis;2137]A way to make repositories hidden except to those who have Push access.[/QUOTE]
That would be the ability to control pull access. It’s certainly on the list: there’s a bunch of code to address it, just all commented out and in need of considerable effort to get it to actually work.
[QUOTE=Rob Galanakis;2147]Auto-create a forum thread here when a new repository is created, which can be used for requests, bugtracking, feedback, comments, etc.[/QUOTE]
That would be pretty easy. Maybe I’ll do that next.
Okay, I’m giving up on this for today. I thought I had it working, but it turns out I don’t. Mercurial is making this much harder than necessary by demanding we use HTTP authentication instead of doing its own custom authentication.
It’s now possible to create private repositories, that only some users can view. This is subject to one rather unfortunate architectural constraint: they all need to be in a special directory private/. This means you can’t make a public repo private or vice versa without changing the name (in which case you may as well just delete it and create a new repo). Unfortunately, it’s difficult to get around this given Mercurial’s (IMO quite unreasonable) choices about authentication.
One last possible course of action does occur to me. I’ll try it tomorrow or so. If it works, all existing private repos will be moved to their more natural home, without the “private/” part of the path, and I’ll implement the ability to switch repos from public to private and vice versa.
Also, for the time being, you can’t alter the list of people with pull access without deleting and recreating the repo. Clearly this is an omission that I’ll fix, I just haven’t done it yet (although deletion followed by recreation is of course a lossless operation).
Okay, private repositories no longer need to have “private/” in their names, so I’ll be able to make them freely switchable back and forth. Admittedly this required a rather large amount of time and involved some unspeakable evil to be committed in terms of implementation ― I had to allow arbitrary web scripts to run a couple of scripts I wrote as root, including the ability to graceful Apache, because of the lameness of hgwebdir.cgi’s permissions implementation ― but correctness demanded it.
Anyway, I should be able to allow modification of privacy and pull lists now.
I implemented modification of privacy and pull lists. It seems to work according to my testing, but that wasn’t entirely extensive, so please report any bugs. Also, I made the <title> (the thing at the top of each tab/top of browser window/etc.) more correct, like “User Control Panel - Manage Repositories - Tech Artists Forums” instead of “User Control Panel - - Tech Artists Forums”.
[QUOTE=Rob Galanakis;2147]Auto-create a forum thread here when a new repository is created, which can be used for requests, bugtracking, feedback, comments, etc.[/QUOTE]
Working on this now. When that’s done, I think the only other thing I have on my to-do list for repos is to try to get a link to tip somewhere in the hgwebdir interface.
What should I work on now? Figuring out how to add a link to the tip revision in the web view? Cleaning up errors, maybe? If there any big new features you’d like, I think some code cleanup is needed. If there’s nothing else that you want to be done except cleanup, it’s probably best not to invest the effort on your time.
I need to round up some people and I’d like to start discussion about the database/protocol discussed in the other thread (about ScriptSpot). I’ll keep you updated when I hear more (talking to another web coder for a wordpress implementation, highend3d, and scriptspot).