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

Re: Current Updated Revision Number

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2003-09-09 01:22:19 CEST

David Waite wrote:
[in response to a proposal for a keyword that behaves like "svnversion"]
>
> I think this is a very overengineered solution to a problem, and will
> add lots of additional complexity in the working copy code.

Maybe. Certainly I cannot see a good (simple) implementation yet, and I would not want to see it implemented in a very complex way.

> If the point is to have a version for customer/user reporting, why not
> base it on repository path rather than revision number? Is making a tag
> and switching over to it really that hard?

That is surely a Good Thing to do. It is harder than just having a keyword which gets updated by Subversion, but it is not Very Hard. For one thing, someone or something has to think of a new name for each new tag. The question is: Will most users find this an acceptable method? Can we help to make it acceptable, by providing example scripts, tag naming suggestions, etc.? Yes, I think we can.

> With a tag you are reporting every version of every file,

Yes - a tag gives a precise identification even from a mixed-revision WC, whereas "svnversion" would have just said "this is a mixture of revisions between X and Y", which is not enough information to reconstruct the working copy later.

> and tagging implies a release process.

It does. That's fine for people who are accustomed to having a release process. I think this discussion applies to people who do not "release" anything but just use Subversion in a very simple way. For instance, I have some of my source files stored in a local repository, and all I do most of the time is commit changes:

~> # edit, compile, test ...
~> svn commit -m "Changed blah..."
~> # edit, compile, test ...
~> svn commit -m "Fixed blah..."
...

I do not even "update", because no-one else accesses this repository so my working copy is always up to date anyway. If I were to want a tag for each commit, which is the sort of scenario that we are talking about, then I would want a script to use in place of "svn commit" that, as well as doing the commit, chose a tag name and created the tag. Could we offer something like these as suggestions:

~/bin/commit-myproj:
[[[
#!/bin/bash
# Commit "~/src/myproj" and tag it.
# Usage: commit-myproj [-m COMMIT-MSG | -F COMMIT_MSG_FILE]
REPOS_URL=file://`echo ~`/vcs/myrepos
svn commit $* ~/src/myproj
svn update ~/src/myproj
TAG=date-`date +%Y%m%d%H%M%S` # date/time stamp
#TAG=rev-`svnversion ~/src/myproj` # WC base revision
#TAG=tag-`svn ls $REPOS_URL/myproj/tags | wc -l` # sequence number 0,1,2,...
svn cp $REPOS_URL/myproj/trunk $REPOS_URL/myproj/tags/$TAG
]]]

commit-myproj.bat:
[[[
@echo off
rem Commit "~/src/myproj" and tag it.
rem Usage: commit-myproj [-m COMMIT-MSG | -F COMMIT_MSG_FILE]
set REPOS_URL="file:///%HOME%/vcs/myrepos"
svn commit %* %HOME%/src/myproj
svn update %HOME%/src/myproj
rem Tag name: date/time stamp, WC base revision, or sequence number 0,1,2,...
set TAG=???
svn cp %REPOS_URL%/myproj/trunk %REPOS_URL%/myproj/tags/$TAG
]]]

Someone with Windows/DOS knowledge would need to fill in the "set TAG=" examples.

> Developers who insist on giving customers/users non-tagged code which is
> potentially from a mixed-revision repository should just write a script
> to supply the version number during their deployment through svnversion.

Yes, that should be acceptable.

> Am I missing something?

I don't know. I am missing something: a grasp of how easy or hard it might be to provide a minimal-effort solution for minimalist users.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Sep 9 01:23:13 2003

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.