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

RE: I miss tags

From: Tom McMillen <thomas.mcmillen_at_mppglobal.com>
Date: 2004-09-28 10:49:27 CEST

[From another lurker who may wish he hadn't joined in ;-)]

> -----Original Message-----
> From: Gary Feldman [mailto:g1list_1a@marsdome.com]
> Sent: 28 September 2004 02:03
> To: Brad Appleton
> Cc: Tom Mornini; users@subversion.tigris.org
> Subject: Re: I miss tags
>
>
> Brad Appleton wrote:
>
> > The conflict is of course that everyone's "mental model" of the
> > problem domain in this case is a little different. Some are
> > strongly biased by experience from one or more tools, some
> > are more biased by what they believe are fundamental principles
> > and concepts behind their own mental model of the "theory of
> > operation" behind the concepts and their implementation.
>
> Thank you for bringing this up, and focusing the discussion on the human
> side. I suspect that many usability experts, if asked to read through
> this thread, would conclude that it shows why software engineers
> shouldn't be building user interfaces.
>
> People use mappings (what you're calling mental models and others have
> called metaphors) to help understand things around them. Donald Normal
> discusses this concept well in The Design of Everyday Things. Issues
> such as architecture and function set, while important to API designs,
> take a back seat to human factors when dealing with the piece of
> software that people have use directly. They come along for the ride,
> but they don't get to drive. WIMP systems need complex APIs, but I
> don't think anyone would argue that the UNIX curses package and GNU
> readline are the way to build the most usable interfaces.
>
> So instead of worrying about the implications for the subversion API, or
> using arguments like "that function is already there, if you do things
> in this way that you find hard to learn or remember," the focus should
> be on identifying a set of mappings or mental models that match the
> mappings people create for themselves. If the API needs to be more
> complex in order to make it easier to learn (with no new functionality),
> that's still a good trade.
>

A while ago someone suggested that people post some examples of how they would like this tagging feature to work, or to at least give example of how they would currently use CVS and show how the svn equivalent would be worse....

if you changed
svn cp
to
svn tag

would this make the mental mapping easier.... You are now no longer copying, but you are now tagging.... (at least in your mind, to svn it is still a copy)

I wonder if it would be possible to set something up so that 'unrecognized' svn commands where fwd'd to a pre-commit hook... (svn tag would go to you basic pre-commit hook, which can then see that you are doing a TAG and fwd it on to your tag script)

This script can then do something more complex
svn tag repos/trunk/project1 release-0.0.1

would create a tag for you under repos/tags/ or whereever you have configured your pre-commit hook...

svn tag repos/trunk/project1 release-0.0.1

issued later would then say sorry, you must force that as you are changing an existing tag....
svn tag --force repos/trunk/project1 release-0.0.1 -m "missed config out of release"

I liked the idea of having a basic SVN (basic := versatile, simple, many uses)
with optional hooks that can be used to add (configurable) things like a tags....

you could extend this perhaps to have
svn tag externalrelease repos/trunk/myproject freddy
svn tag internalrelease repos/trunk/myproject kruger

svn branch repos/trunk/myproject filepermissions
svn spike repos/trunk/myproject filepermissions

etc....

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Sep 28 10:45:32 2004

This is an archived mail posted to the Subversion Users mailing list.

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