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

Re: format of svn:author

From: Mark Mielke <mark_at_mark.mielke.cc>
Date: Tue, 03 Jan 2012 12:53:39 -0500

On 01/03/2012 12:27 PM, Stefan Sperling wrote:
> On Tue, Jan 03, 2012 at 12:11:20PM -0500, Mark Mielke wrote:
>> Other solutions provide these capabilities out of box.
> Could you point out which solutions exist so people can take a look at them?

GIT, ClearCase, and Perforce are the ones I use.

GIT has name, email, signing keys, and others but is not widely used in
our organization at this time. The original start of this thread was a
person talking about GIT and mapping attributes from GIT to Subversion
and how Subversion didn't seem to have the right attributes to do this.

ClearCase, as mentioned, stores both a "current owner" and a "creation
event". The "current owner" is in native format - the UNIX uid#/gid#,
and mapped back to a UNIX username/groupname on demand. The current
owner is more useful for access controls. The "creation event" contains
a string which includes the username, domainname (NIS), and fullname. We
have a customization against ClearCase that adds in submission
authentication to support shared UNIX accounts that will tie a unique
identifier to the submission.

Perforce has an account management system of its own. Which isn't
necessarily an end goal on its own, but when tied with a synchronization
system such that Perforce accounts match upstream accounts, it does work
fairly well.

But these are just examples of what other people have done. The
requirements are pretty straight forward:

1) Require a means to reliably determine the AUTHOR of a changeset.
Reliable here means machine consumable in a standard format which all
tools are aware of because the standard is documented.

2) Require all native output from the tool (such as "svn log") designed
to be read by humans to include a convenient and easily readable format.

3) Provide a standard convention or protocol for 3rd party tools to
reliably determine either the unique identifier or the humanly readable
expansion from Subversion. Either provide additional information in the
commit itself, or provide a mechanism to either lookup the information,
or a mechanism to lookup how to get the information.

GIT uses attributes. ClearCase uses attributes. Perforce uses lookups.

> You can keep criticising us all you want, it won't change a thing
> if you don't also explain in detail what needs to be changed.
> We cannot read your mind to obtain a functional specification.

I know. That's why I wanted to go away and think before coming back.

I am trying to determine where we would like to go next, and although
Subversion has been a favourite of mine since 2003 or so, every time I
try to seriously consider it, it seriously disappoints me. Our
organization will put time and money into the direction we choose - but
I can't responsibly select a tool which does not meet our requirements
no matter what my fancy.

I've been waiting a long time for Subversion to come of age. I've
monitored throughout. From time to time, I've tried to help. It is
disenchanting when I see new solutions come out of nowhere (i.e. GIT)
that already meet requirements out of box with authors and contributors
that already understand the problems and the solutions which seem to be
extremely difficult to implement in Subversion. Everything - even things
as simple as this problem - seem like an incredibly chore in Subversion
land.

I'm probably wrong for being frustrated, and I'm probably wrong for how
am I approaching this. I should probably just sit back and watch again
for a while. I'm sure you haven't appreciated my criticism, and for many
of you it is probably not deserved. You have your itches to scratch, and
you are itching them. Why should you care about my itches? You are being
nice to me to bother to consider my itches at all. :-)

-- 
Mark Mielke<mark_at_mielke.cc>
Received on 2012-01-03 18:54:14 CET

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

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