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

Re: exporting an uncommited file and keywords

From: Ben Reser <ben_at_reser.org>
Date: 2004-02-16 19:15:14 CET

On Mon, Feb 16, 2004 at 05:41:22AM -0500, John Szakmeister wrote:
> FWIW, I'm -1 on using 'U' for an uncommitted entity, and 'M' on using
> one that has but locally modified.

M is already in there. So are you really -1 on the current
implementation? If we took the M out then locally modified versions
would be indistinguishable from the $Id: $ on the basis of revision
which kinda defeats the purpose.

Removing the version number entirely in such a case also loses
information that could be useful. If someone takes and accidentally
releases and locally modified but uncommited copy then you can find the
version it was modified against so you can more easily merge the change.

Additionally the M makes it possible to write a tool that looked for
such an error in the dist package and tells you.

> In my mind, it doesn't make it any easier for the user. I'm fine
> with removing the author, or using '(unknown)'. Although now that I
> think about it, I'd rather we just leave the field blank.

M and U aren't any harder to remember than our status flags. If they're
documented then they'll be useful. I'm okay with leaving the author
field blank. But I don't tihnk the version field should be blank. We
can do useful things with it. There's nothing really useful we can put
in the author field that doesn't run into potential namespace issues.

-- 
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 16 19:15:28 2004

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.