Erv Walter wrote:
> Let me clarify. "Project" = "Open Issue" for my company. Just a
> terminology thing. Developers only work on assigned projects which will
> have project IDs autogenerated when they start working on them.
> Also, I was just giving you a data point for my company. I fully
> understand that other companies will be different as will open source
> projects. I just wanted to clarify that the list of assigned
> tasks/projects/issues may not always be secret and require
> authentication internally for a corporate use of subversion. Yes, we
> may not publically release the details until we have a fix, but we don't
> make an attempt to hide the details frmo other developers internal to
> the company.
But now imagine someone in your company working from home or while
traveling. Then your firewall won't prevent anyone in the world to see
your open issues and you'd have to implement authentication too ;)
> If my opinion counts for anything, I am more in favor of an extension of
> the existing seperate text box for issue numbers (vs autocomplete in the
> log message). I would also love to see a configuration option (via
> property, etc) that disallows free text typing in the issue text box and
> only allows them to choose from the list. We have had many problems
> with typos being made and then the wrong issue/project getting
> associated with a commit without any obvious error. By limiting
> developers to a finite set of issue/project numbers we could really
> clean this up.
Just to clarify: if such a list of open issues is available,
editing/inserting the issue number in the separate edit box won't work
anymore because in that case there will be only a simple listbox where
you can choose an item but not edit it.
> Anyway, I'm just excited to see the ideas being discussed, and we can
> probably come up with a solution that will work with our internally
> developed project managment system no matter what solution you settle on
> (as long as you don't make us implement DAV :). Thanks for the hard work!
The more I think about that, the more I like the idea (sorry ;)).
Can someone with an apache/PHP setup please try something for me?
- create a section which you serve via DAV (the mod_dav module is loaded
if you've setup subversion!). Then put a PHP script in there which
generates a simple text file. (I'm not sure if PHP is even invoked for
such a section or not).
- Can you point your browser to that PHP file and see the text file or
the PHP script?
- Create a working copy with a new folder, add an svn:external pointing
to the folder served by DAV and do an update. Do you get the text file?
If that works, then the DAV way definitely is the way to go! Because
AFAIK you can get the username which authenticated itself in a PHP
script via apache variables and then generate an xml file accordingly.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Feb 22 20:50:18 2005