[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: Stephen A. Jazdzewski <steve_at_jazd.com>
Date: 2006-12-07 23:36:14 CET

----- David Glasser <glasser@mit.edu> wrote:
> 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.

I agree. This would not replace this kind of work flow.

> 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.)

Thank you. After a brief delay from a job change, I did compile and
install mucc today.

Here is an example of my proposed promote work flow using mucc:

General users pickup all current documents from svn://server/current

svn://server/current/doc/employee is currently a copy of

I need to make a change to the the latest employee manual, so first
I make a branch from the latest (trunk). The latest version is
slightly newer than the tag, I just have not promoted it yet.
So I will branch at latest.

$ svn copy svn://server/latest/doc/employee svn://server/branch/doc/employee/newDirective

I then switch my work area to the new branch

$ svn switch svn://server/branch/doc/employee/newDirective employee

Time to do my edits

$ ooffice2 employee/manual.odt
svn commit -m "Check point" employee
svn commit -m "New directive" employee

Switching back to the latest and merge my branch

$ svn switch svn://server/latest/doc/employee employee

$ svn merge -r27:29 svn://server/branch/doc/employee/newDirective employee

$ svn commit -m "Merged r27:29 branch/doc/employee/newDirective to latest" employee

Make a tag

$ svn copy svn://server/latest/doc/employee svn://server/tag/doc/employee/v1.1 -m "Updated with the new directive"

Now promote the svn://server/current/doc/employee to this tag
so the general employee population can now see it.

$ mucc -m "promoting new directive v1.1" rm svn://server/current/doc/employee cp 31 svn://server/tag/doc/employee/v1.1 svn://server/current/doc/employee

>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.

I hope this makes my intent a bit clearer. I have no issue continuing
to use mucc instead of a new svn command. But I still think it should
be considered as a new command since it makes things a bit easier for
non-developers to use the repository. Developers just need to keep
non-developers away from all but the svn://server/current tree.
Developers can continue to the rest of the repository as explained
in the 'recommended svn practices'.

I apologize if my use of 'latest' instead of 'trunk' has confused
anyone. Trees have branches, but they don't have tags, so why use trunk :)

Stephen Jazdzewski from my new job at http://www.CBTNuggets.com

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 7 23:36:43 2006

This is an archived mail posted to the Subversion Dev mailing list.