Stephen Jazdzewski

 

Proposed new command for SVN

To: dev@subversion.tigris.org
Subject: promote, proposed new svn command
Sent: Sat Nov 11 09:35:56 2006

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.
 

Is the trunk going too far?

 

Command line friendly tree

 

non-developer friendly