This new promote command would be like a server side switch command.
The new promote command would have at least these two forms:
svn promote file:///svn/tag/project/alpha6.1 file:///svn/build/project
and
svn promote -r2264 file:///svn/build/project
In both of these examples, file:///svn/build/project already exists
as a result of an earlier copy command like
svn copy file:///svn/trunk/project file:///svn/build/project
In the first example, tag alpha6.1 is revision 2264 of
file:///svn/trunk/project.
The execution of the promote command would have to same result as
svn delete file:///svn/build/project
svn copy -r2264 file:///svn/trunk/project file:///svn/build/project
or
svn delete file:///svn/build/project
svn copy file:///svn/tag/project/alpha6.1 file:///svn/build/project
The reason I would want the new promote command is I like using a slightly
different naming scheme for my repositories. The addition of the
promote command would make it much easier for users to understand and
work with this scheme.
First, I don't like 'trunk', instead I use 'latest'. Also I use the
singular 'tag' and 'branch'. I think this makes the command line read
nicer.
svn copy file:///svn/latest/project file:///svn/tag/project/alpha1.1
svn switch file:///svn/tag/project/alpha1.1 working
The directories do contain tags and branches, but you almost never
refer to more than one at a time on a command line.
In addition to 'tag', 'branch' and 'latest', I like to use 'current',
'build' or 'release'. These directories have the same form as 'latest'
or 'trunk'. That is, the tag or branch version name is not encoded
in the URL. Like tag, they should not be committed to directly or
used like a branch.
This scheme comes in handy if the URL is exported or updated via a
hook script for others (non-developers or authors) to get the most current
approved versions of files.
In this scheme, authors work in 'latest', 'tag' and 'branch'.
Once they are ready, they can publish (promote) their work, to 'current'.
People not savvy enough to switch their local areas to the correct place
can always find official current versions under the current directory.
For building, if my local build directory is currently switched to
file:///svn/build/project
All I need to do is update the directory before I do my build.
The promote command would make the management of a directory scheme like
this easier for users and programmers to understand. Also I think
this will remove possible conditions where the directory disappears for
short periods of time during the delete and copy process. I don't think
I have been able to do this as a single atomic commit.
If a current svn developer is not as excited as I am about the promote
command, I do have the skills needed and
may have time to make this enhancement myself. This would be my very first
contribution to subversion and I suspect adding this command
may take a more complete understanding of the architecture.
I am also not married to the name 'promote' for this feature.
Thank you for your consideration.
-Stephen Jazdzewski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 15 22:52:36 2006