You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Stephen A. Jazdzewski" <st...@jazd.com> on 2006/11/14 16:13:13 UTC
promote, proposed new svn command
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 non-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. I do think
this would be the best name for this command.
Thank you for your consideration.
-Stephen Jazdzewski
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: promote, proposed new svn command
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Nov 16, 2006, at 10:54, Thomas Wicklund wrote:
> What might be useful is the ability to perform a generalized set of
> actions as a single new repository version, something like (this is
> obviously not a suggested syntax but I think expresses the idea):
>
> svn {
> delete URL2
> copy URL1 URL2
> }
>
> or (
>
> svn {
> copy TRUNKURL/path1 TAGURL/path1
> copy TRUNKURL/path2 TAGURL/path2
> copy TRUNKURL/path3 TAGURL/path3
> }
>
> Multiple svn commands can be used today, but each one creates a new
> revision, which is a bit annoying when later having to wade through
> logs containing a list of revisions which perform one logical
> operation.
I believe mucc will already let you do just that.
http://svn.collab.net/repos/svn/trunk/contrib/client-side/mucc.c
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
promote, proposed new svn command
Posted by Thomas Wicklund <wi...@eskimo.com>.
Stephen A. Jazdzewski writes:
> 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
I also frequently copy over an existing dirctory in a repository. The
delete / copy pair is a bit annoying, though not difficult to manage
in a script.
What might be useful is the ability to perform a generalized set of
actions as a single new repository version, something like (this is
obviously not a suggested syntax but I think expresses the idea):
svn {
delete URL2
copy URL1 URL2
}
or (
svn {
copy TRUNKURL/path1 TAGURL/path1
copy TRUNKURL/path2 TAGURL/path2
copy TRUNKURL/path3 TAGURL/path3
}
Multiple svn commands can be used today, but each one creates a new
revision, which is a bit annoying when later having to wade through
logs containing a list of revisions which perform one logical
operation.
Thomas Wicklund
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org