could it be that http://trac-hacks is dead?
rupert.
Yup, all I get is "Waiting for trac-hacks.org..."
What's the best way of mirroring the trac-hacks.org site?
Any ideas appreciated.
/Lars
On Nov 6, 2:31 pm, Lars Stavholm <st...@telcotec.se> wrote:
> rupert thurner wrote:
> > hi,
>
> > could it be thathttp://trac-hacksis dead?
Using SVN 1.4 on trac-hacks.org (and on t.e.o. BTW) would be a good
start: svnmirror could be used.
SVN is widely used and has great, user-friendly GUI apps (such as
TortoiseSVN)...
Cheers,
Manu
Rupert was kidding, I guess.
BTW: svn 1.5 is on the way, so if someone plans to migrate from pre-1.4
to a recent version, it might be a good idea to wait for a couple of
weeks.
Rainer
Chris
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.
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.
Axton Grams
That's all good ideas.
How about mirroring the Trac site itself?
/L
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
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
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "Trac Users" group.
> To post to this group, send email to trac-...@googlegroups.com
> To unsubscribe from this group, send email to trac-users-...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/trac-users?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>
>
2 hours long gone.
> 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
What's PyPI?
/L
I meant the trac-hacks.org contents.
/L
Over thought? Today makes 2 out of the 3 times I've tried to
'show-off' trac hacks and it's been down. All three have been to
separate groups where I was advocating the use of Trac. Extensibility
through plugins are a life-line. We need a solution that doesn't keep
putting kinks in that line.
All I care about are the plugins themselves and especially the
directions on installing and setting up each plugin.
What the owner of trac-hacks is doing for the community is fantastic -
we just need to have a good solution in place to help support the
existing effort.
-Rich
On the other hand, I understand that trac-hacks has undergone some
changes recently (moved to a new machine I believe?) and therefore
understand how this downtime can happen and am grateful for those
maintaining the service.
Best,
Chris
This has been a particularly bad time for Trac-Hacks, through a series
of unfortunate events. First the half month outage because I was on
holiday, then since the that Apache has been hanging fairly frequently.
I haven't had time to investigate this, but I'll have time when I return
home next week.
> All I care about are the plugins themselves and especially the
> directions on installing and setting up each plugin.
>
> What the owner of trac-hacks is doing for the community is fantastic -
> we just need to have a good solution in place to help support the
> existing effort.
Is there something that Noah's read-only mirror of TH doesn't provide?
--
Evolution: Taking care of those too stupid to take care of themselves.
First of all, thanks very much for getting t-h back up in October and
the further work on moving it to the new server and working with apache.
>> existing effort.
>>
>
> Is there something that Noah's read-only mirror of TH doesn't provide
A prominent link from trac.edgewall.org, a url like
mirror.trac-hacks.org, or the ability to easily be pointed to as
"www.trac-hacks.org" when the main server goes down.
Best,
Chris
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 <kan...@rpi.edu> 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 <st...@telcotec.se> wrote:
>
> >> Axton wrote:
>
> signature.asc
> 1KDownload- Hide quoted text -
>
> - Show quoted text -