[Trac] Re: Begginer
On Nov 9, 2007 2:57 PM, Tyrone Hed [EMAIL PROTECTED] wrote: Rodrigo, Install the Windows version if at all possible. The Unix version is a killer. -Original Message- From: [EMAIL PROTECTED] Sent: Nov 9, 2007 2:55 PM To: Trac Users trac-users@googlegroups.com Subject: [Trac] Begginer Good morning, I have acceced Trac tool to project management and I got interested on the project. Though ,I don`t have any experience in Phyton, I`m a Java programmer. I have never programmed using CGI and I use to structure my programs in MVC. I would like to ask if anyone of the group could tell me how I can start using this tool in my host server. I tried to follow the instructions on the web page ttp://trac.edgewall.org/wiki/TracGuide , but I could`t make it. I have already installed Apache that points to http://localhost/trac. but it doens`t look for the .cgi. Can anyone help me with this problem? Does anyone know if there is any brazilian discussion group about it? Thanks, Rodrigo There is no Unix vesion per se. Trac is written in pure python--it is architecture independent. Can't be helped if it's difficult to compile the dependencies correctly on some platforms. That's not Trac's fault. Erik --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Trac] Re: Begginer
On Nov 9, 11:37 pm, Samuel A. Falvo II [EMAIL PROTECTED] wrote: writing your own? I know for a fact that, e.g., MoinMoin wiki has a bug tracker plug-in for it (the Darcs website is implemented this way, for example), and Trac's other features can be implemented via various http://bugs.darcs.net is based on http://roundup.sourceforge.net, http://wiki.darcs.net is moinmoin as you correctly state. rupert. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Trac] Re: Begginer
On 11/09/2007 05:37 PM, Samuel A. Falvo II spoke thusly: I am getting pretty sick of this question being asked over and over again, so I'm going to write something to address this question once and for all. Excellent, Samuel! You should submit this to several magazines/newspapers or whatever as an editorial. At the very least post it on a blog somewhere! Thanks for your thoughtful description of the issues we all live with every day. -Dan -- C. Daniel Chase [EMAIL PROTECTED] Web Systems Analyst (423) 425-4003 The University of Tennessee at Chattanooga http://www.utc.edu/ Get Firefox! http://www.spreadfirefox.com/?q=affiliatesid=58708t=1 HighEdWebDev 2007 http://highedweb.org/2007/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Trac] Re: Begginer
Rodrigo, Install the Windows version if at all possible. The Unix version is a killer. -Original Message- From: [EMAIL PROTECTED] Sent: Nov 9, 2007 2:55 PM To: Trac Users trac-users@googlegroups.com Subject: [Trac] Begginer Good morning, I have acceced Trac tool to project management and I got interested on the project. Though ,I don`t have any experience in Phyton, I`m a Java programmer. I have never programmed using CGI and I use to structure my programs in MVC. I would like to ask if anyone of the group could tell me how I can start using this tool in my host server. I tried to follow the instructions on the web page ttp://trac.edgewall.org/wiki/TracGuide , but I could`t make it. I have already installed Apache that points to http://localhost/trac. but it doens`t look for the .cgi. Can anyone help me with this problem? Does anyone know if there is any brazilian discussion group about it? Thanks, Rodrigo --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Trac] Re: Begginer
Rodrigo, Install the Windows version if at all possible. The Unix version is a killer. Ok, now please stop. We all understood you have issues installing Trac on a AIX system. *nix systems does not sum up in AIX. The issues you encounter, although real, do not validate or invalidate a system. I hope we'll find a workaround so that you can install Trac on your AIX system. You may say you would not recommend installing Trac on AIX, but I don't think you can generalize your own experience as installing Trac on *nix is more difficult than it is on Windows. It may even be easier, depending on the distribution you use, as with a decent package manager, it can be as simple as installing Trac and the package manager will install all the dependencies. Cheers, Manu --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Trac] Re: Begginer
I have already installed Apache that points to http://localhost/trac. but it doens`t look for the .cgi. Can anyone help me with this problem? I would recommend you use mod_python (TracModPython) except if you have some specific requirements. CGI method gives really bad performances. Please post the relevant section of your apache configuration file, along with the command you used to create your Trac environment - the one with trac-admin. Cheers, Manu --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Trac] Re: Begginer
I am not attempting to use Apache. I am running under tracd alone. And, frankly, telling me that yet another variant should be tried does not inspire confidence. I have to wonder: is this the way you guys planned this to be? With guess-which-version works with your stuff? -Original Message- From: Emmanuel Blot [EMAIL PROTECTED] Sent: Nov 9, 2007 3:30 PM To: trac-users@googlegroups.com Subject: [Trac] Re: Begginer I have already installed Apache that points to http://localhost/trac. but it doens`t look for the .cgi. Can anyone help me with this problem? I would recommend you use mod_python (TracModPython) except if you have some specific requirements. CGI method gives really bad performances. Please post the relevant section of your apache configuration file, along with the command you used to create your Trac environment - the one with trac-admin. Cheers, Manu --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Trac] Re: Begginer
I am not attempting to use Apache. I am running under tracd alone. I was replying to rodrigo here. If you use tracd, the cgi vs. mod_python choice does not apply. And, frankly, telling me that yet another variant should be tried does not inspire confidence. I have to wonder: is this the way you guys planned this to be? With guess-which-version works with your stuff? No, all of them works, but performance, dependency complexity, compatibility with other modules (PHP to name it), etc. do matter. This true complexity in the choice of the installation kind is the price to pay to support multiple OS, multiple web server, multiple installations, etc. Cheers, Manu --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Trac] Re: Begginer
On Nov 9, 2007 1:00 PM, Tyrone Hed [EMAIL PROTECTED] wrote: And, frankly, telling me that yet another variant should be tried does not inspire confidence. I have to wonder: is this the way you guys planned this to be? With guess-which-version works with your stuff? I am getting pretty sick of this question being asked over and over again, so I'm going to write something to address this question once and for all. Back in the 1990s, Microsoft thought, You know, there is a real market for interchangable parts to programs. OLE 1.0 was what had initially shown them the light. However, there were a number of technical issues that interfered with capitalizing on this market, so thus they invented COM. COM offers components with standardized interfaces that, indeed, makes good on their promise of interchangable parts. But all was not well; COM had run into severe usability issues in the form of lack-luster and ill-defined security mechanisms and, of course, DLL-hell. Of relevance to your issues, I'm focusing on the DLL-hell that ensued. A whole industry evolved out of DLL hell, called installers. Installers took care of placing things where they needed to be, updated the registry, and so much more, all to give the end-user the illusion of a seamless, effortless install. Largely, it worked. But every time Microsoft alters some technology, you inevitably end up dealing with DLL hell again -- what version of MSVCRT.DLL does THIS program need, and why is it incompatible with THAT program? These issues continue to plague Windows developers today, albeit not as much as they used to, because Windows 2000 introduced per-program library path searches and registry key organizations. Still, it happens more often than you think. I know -- I used to administer a large collection of Win2K and 2K3 servers for a significant ISP. Still, despite all this effort, the problem of re-usable software remains unsolved. People are all the time re-inventing the wheel, because programmers are realizing that wooden wagon wheels don't fit on Ferraris, and wheels for a Toyota Prius don't work well on shopping carts. The end result is a multitude of programs which depend on a multitude of different components, to this very day. It seems that the only thing truely reusable is the _concept_ of a wheel, while the physical reiification of that concept is as domain-specific as the domain to which it's applied. So, why can Windows largely just work and not Unix? Let's ignore the subjectivity of this question, and concentrate on what can be objectively measured from the perspective of a Windows developer. Frankly, it's because Microsoft Is God when it comes to the Windows platform. They decide (A) what CPU the OS runs on, (B) what libraries get searched, where, and when, (C) the semantics of various registry keys, etc. There is never any question about what distribution of Windows you have -- they have total, precise, and absolute control over all distributions of Windows. (Footnote: It turns out this isn't entirely true; there are a myriad different implementations of WinCE, and try as they might, not all implementations are compatible with each other. But, we see distinct parallels between WinCE and Unix-derived platforms, in that Microsoft _doesn't_ control (A) when it comes to the embedded world. It's amazing how flimsy a tripod becomes when you kick out one of its legs, eh?) This is not the case with Linux, BSD, Solaris, or other Unix-type OSes. Here, POSIX (the common API all these OSes share) is a paper standard, not an implementation standard. Therefore, differing implementations of the API may have subtly different semantics which, largely, isn't usually of any real concern. Part of those semantics covers how the shell finds executables, how the dynamic linker finds shared libraries, and other non-kernel-related stuff. Remember, POSIX covers not just the kernel API, but the user's experience and expectations as well. It is a shame, but POSIX is more nebulous about the latter than the former; it has to be, or else there is no point in having multiple vendors competing with each other in the free market. An all-encompassing standard is no different than a monopoly, and POSIX was careful to avoid the pitfalls of stifling unique selling points of various vendors. Nonetheless, the open source community has discovered that it largely has already solved the code reusability problem long before Microsoft had identified it as a potentially profitable market. There are programs and libraries distributed all the time, and no proprietary, binary-level interface is needed. The problems of coupling programs together seems to always depend on filesystem-level or shell environment dependencies. It almost never depends on anything else. This speaks volumes of the technique, considering, after all, there is no grand overlord, no Binary God, no planned design to cover this interoperation. It is an organic evolution,
