pypi? oh ... a very good idea ... created http://trac-hacks.org/wiki/EggCookingTutorial/publish.
about distributed version control, rainer: of course i was kidding. looking e.g. at http://repo.or.cz/git-browser/by-commit.html?r=git.git shows the "release often" world. to release so often and to have every feature in one branch, who wants this? it just makes the display of the repository in a graphic log slow. and this easy merge stuff .. a real developer need to know the revision number where he branched off. and who the h... wants to have more than one branch, nobody needs stable, testing, unstable. also this linux torvalds guy with his obsession in little easy to understand patch policy and this tedious lieutenant system, how should that work? a real developer puts the change sets immediatly into trunk which then gets more attention and quick feedback from other developers. it also prevents choosing the generals of the branches, such decisions do not lead to anything. and why would i want to merge in some feature of a developer i do not even know? i prefer of course copying that line by line out of a trac ticket, find the file, and carefully handcraft that patch into the file! and after the next upgrade i do it of course some code might have been changed exactly there, which deserves all the attention to handcraft it again. of course there are many other advantages: writing some code and publish it via patch to a trac ticket is also very appealing. it makes sure not too many people are using it and bothering me with stupid comments about the low quality. and it also makes sure it does not get too easy merged in into trac which helps keeping it slim. also the change history does not get overloaded, which makes it easy to follow, see http://trac.edgewall.org/timeline?from=11%2F07%2F2007&daysback=14&changeset=on&update=Update. i mean why should one want to support christian anyway, if he can do it alone? having commit access to a few people of course guarantees that nobody comes up easily with strange branches nobody wants. we see how bad these branches are already with security, workflow, context. they just make the release cycle long. after all, what should i do with the whole repository on my disk where space is anyway not available? mirroring, this would be just a bothersome side effect. who would have an interest to spread out this repository to an arbitrary number of sites where you have no idea any more if it is the original not virus prone code? rupert. On Nov 6, 5:51 pm, Noah Kantrowitz <[EMAIL PROTECTED]> wrote: > How about we just wait the 2 hours for an admin to notice and kick > apache in the head? > > I think this is being seriously over-thought. If people need the code > for plugins, it should all be available on PyPI as a "mirror" (assuming > the author was wise enough to push copies there). > > --Noah > > > > Axton wrote: > > On Nov 6, 2007 11:13 AM, Lars Stavholm <[EMAIL PROTECTED]> wrote: > > >> Axton wrote: > > >>> On Nov 6, 2007 10:53 AM, Emmanuel Blot <[EMAIL PROTECTED]> wrote: > > >>>>> SVN 1.4+ has svnsync available which is also an option. It can be set up > >>>>> to run as a commit hook and push out/sync changesets to a list of mirror > >>>>> repositories or just be scheduled for periodic sync. > > >>>> Sure but this means TH needs to push information - therefore an > >>>> operation is required on TH when a new mirror appears or needs to be > >>>> removed. > > >>> For mirrors, what about creating a daily copy of the repo using > >>> 'svnadmin dump', then posting the file for public download. Sites > >>> that wanted to mirror could then fetch a copy on an interval and load > >>> it using 'svnadmin load'. > > >>> To ensure service, it could be worked out that in the event of a > >>> failure at trac-hacks, a repository could be designated as a backup > >>> working site. The backup site could be kept up to date using svnsync > >>> using a post-commit hook. Changes on this site could be loaded to > >>> trac-hacks when service is restored. > > >> That's all good ideas. > >> How about mirroring the Trac site itself? > >> /L > > > How about the same arrangement so far as the schedule; just tgz the > > resulting directory structure from trac-admin hotcopy. > > > I have a hosted machine I can offer as a mirror if the owner of TH > > will work with me to make some type of arrangement. Host has 500gb > > monthly transfer, runs Trac 0.10.3.1, svn 1.4.2, apache 2.2.4, python > > 2.4, sqlite 3.3.10, linux x86. > > > The authentication will be a little tricky, as my site may not be > > configured like the TH site. I use digest auth via TracAccountManager > > 0.1.3dev-r1844. The same set of htdigest credentials are used to > > manage svn commit access. > > > Axton Grams > > > > > > > signature.asc > 1KDownload- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
