I can't figure out what the objective of this mail was. Was it just a general rant about any number of problems with the universe, or was there some specific point?
On 11/7/07, rupert thurner <[EMAIL PROTECTED]> wrote: > > 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 - > > > > > -- Evolution: Taking care of those too stupid to take care of themselves. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-users@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
