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

Re: promote, proposed new svn command

From: David Glasser <glasser_at_mit.edu>
Date: 2006-11-15 23:02:09 CET

On 11/11/06, Stephen A. Jazdzewski <steve@jazd.com> wrote:
> 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

Generally, folks use merges to update paths to the newest version from
somewhere else; that way the history lets you see what has changed
since the last "push" instead of seeing it as a delete-and-replace.

If you really want to do that, you can certainly
delete-and-replace-with-history in a single commit, at the API level.
The svn client only lets you do this in working copies, which is not
appropriate for managing directories of branches. There is a
"multi-URL-command client" in the contrib/client-side directory of the
Subversion distribution called "mucc" that lets you do this:

mucc rm file:///svn/build/project \
     cp head file:///svn/tag/project/alpha6.1 file:///svn/build/project

(You can build it with "make mucc"; "make install-contrib" will
install it and a few other random things.)

I don't see a particular need to integrate this into the svn client,
because it is not really in line with recommended svn practices but
still is available via the API (to clients like mucc) for those who
choose to work this way.

--dave

-- 
David Glasser | glasser_at_mit.edu | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 15 23:10:05 2006

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.