[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [TSVN] Trac/bugtraq - Ticket to Changeset link [was: Re: Trac [was: TortoiseSVN 1.1.1 released]]

From: Mark Phippard <MarkP_at_softlanding.com>
Date: 2004-10-27 17:03:30 CEST

Lars Klose <lars.klose@klst.com> wrote on 10/27/2004 10:57:24 AM:

> Mark Phippard wrote:
> > Granted. You would also want to use a hook if you wanted this
validation
> > to be 100%. I am simply trying to spec out something that would be as

> > user-friendly as possible. I think that by allowing a feature to exist
in
> > the UI it provides more opportunity to provide a robust user
experience.
> > The pre-commit hook happens pretty late in the process and forces the
user
> > to start over.
>
> I think the features we're discussing here should be very cautiously
> separated into features that provide and force the integrated use of a
> bug tracking system at a basic level and others that deliver a
> convenient user interface for this integration.
>
> The first group should work independently of a specific svn client, and
> on the server side. With Trac this basically works well and is achieved
> through pre-commit and post-commit hooks.
>
> The user's experience could be better though because he is forced to
> remember ticket numbers and enter them in a specific format into the
> commit message.
>
> This leads to the second group of features (and to the reason for my
> first posting): giving the user as little headaches as possible when
> forced to use the bug tracking system is the *svn client's* job, e.g.
> TSVN's.
>
> Having things separated like this may lead to much better acceptance of
> the whole concept. I could still use some non-bugtraq-enabled svn client

> when needed (IDE-integration comes to mind!) without risking to break
> the integration. And if needed you could add bugtraq support in a
> similar way to any other svn client than TSVN.
>
> It all boils down to a well-defined interface between svn, svn clients
> and issue tracking systems.

I find this post confusing because I assume its intent is to disagree with
me, but I feel like what you actually wrote is in support of my proposal.
I believe the validation should be part of the UI for precisely the
reasons you state. It provides the best user experience, and allows an
administrator to get around it when necessary by using the command line
client.

Of course it should be noted that if you did not want validation, you just
would not enable it. In the corporate realm, with Sarbanes-Oxley, and all
of the other auditing issues to contend with, I do not think it is a
stretch to think that a lot of users will want a valid issue ID associated
with each commit.

Mark

_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Oct 27 18:07:45 2004

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.