with svn its very simple: use one repository and use as many trac instances as you think is good. on the url the developers cannot notice it it is one or more rep's.
-solo. On 8/5/07, bert <[EMAIL PROTECTED]> wrote: > > thanks Michal ! > > I agree with your comment about end users and that they cannot use the > trac tickets directly or it will screw everything up. my end users are > not "coders" or developers in any way so I agree they would be lost > with all the parameters. > > so let me rephrase the question : how do you know you should use 2 > repositories and 2 trac instances in a big project, instead of 1 > repository and trac, with 2 directories (2 components) ? > > in my case I have an application on the PC which consists of a GUI and > driver part, but the driver could potentially be used by several > different type of GUI applications. > > the driver communicates with a piece of hardware, for which the > firmware and electronics are in 2 different repositories (because > several versions of firmware could work on different variations of the > same electronics platform?) > > so right now i have 4 repositories which deal with 4 parts of the > project (host sw, driver, firmware, electronics design) > > maybe some of the repositories should be merged and parts moved into > directories, so I need less trac instances. > > what is your opinion? > > > On Aug 5, 9:40 am, "Michal Konvalinka" <[EMAIL PROTECTED]> > wrote: > > Hi, > > the qeustion is - is the design of your repositories the right way? > > One repository can be used for let say - the same client and different > > projects. There are many styles of repository design. You can set up > > different users/permissions for different parts of your repository > > etc. But I suppose you already know this. > > > > In your case what I recommend - If end users don't care about > > repositories and things like that, let them enter the bug/wish in the > > simpliest form into another bug reporting system. and Your developers > > will get new bugs/wishes and decide if it's a relevant bug or wish or > > enhancement and copy / paste it with priorities and other flags to > > correct Trac instance. > > > > I suppose there is a way to automatically insert tickets into Trac - > > it's a database and there are libraries for SQLite or other RDBMS in > > PHP and Python. But I would never let end users access Trac directly > > because they don't understand things like minor/major/critical etc. > > Only developer can set these values properly. > > > > Best regards, > > Michal > > > > On 04/08/07, bert <[EMAIL PROTECTED]> wrote: > > > > > > > > > hi, > > > > > i have a big app consisting of 4 svn repositories each with their own > > > trac instance. > > > > > they are not in a single repository because each of the 4 parts could > > > evolve at different development speeds, etc. > > > > > since the 4 parts make no sense to the end user but only to the > > > developers, i would like to make a web form that lets people submit a > > > bug or feature request, store it in a database and then manually > > > approve the bug/feature behind the scenes and have it inserted into > > > the right trac instance. > > > > > is there a way to automatically submit tickets to a trac instance, say > > > from a php web app or from python? > > > > > thanks, > > > Bert > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
