I think your plan is good in spirit, just a bit confused with the
details. I imagine you haven't actually done any branching or merging
with svn yet, just read about it. :-)
On Mon, 2004-04-26 at 20:45, Henderson, Michael D wrote:
> The tech team creates two branches, one for QT testing and the other
> for holding tested and approved changes.
>
> $ svn copy svn://zinc/batch/trunk svn://zinc/batch/branches/rc1.test
> -m "Release Candidate 1 QT sandbox"
>
> $ svn copy svn://zinc/batch/trunk
> svn://zinc/batch/branches/rc1.accept -m "Release Candidate 1
> production path"
>
> Question: Is it possible to svn copy svn://zinc/batch/trunk
> svn://zinc/batch/branches/rc1/test instead?
Sure, why not? You can create a branch whereever you want. The
/branches area of the repository can be organized however you wish.
Nothing is forcing you to create branches directly within the top level
of /branches.
>
> The developers can work on the trunk of the repository to their
> heart's content. The developer commits a change and send a note to the
> tech team with the file paths and the revision number. As changes come
> in from the developers, the tech team copies the changes into the
> branch.
>
> $ svn copy --revision {developer's rev}
> svn://zinc/batch/trunk/{developer's path}
> svn://zinc/batch/branches/rc1.test/{developer's path}
>
That's not how you copy changes from one branch to another. You need to
read about the 'svn merge' command. And the developer only needs to
tell the tech team: "merge these revisions from trunk to branch."
There's no need to list file paths, because each revision already
represents a changeset, and thus a list of specific file paths.
> On the test box, the tech team does a export from the QT branch to
> sync the test box.
>
> $ svn export svn://zinc/batch/branches/rc1.test/{developer's path}
> batch/{developer's path} --force
>
> Question: This seems like overkill to me, but I haven't been able to
> export a single file. When I try, I get the following error (this is
> in 1.0.2).
>
Just 'svn cat URL' to get a single file. No need to 'svn export'.
>
> After the test team blesses the change, the tech team does another
> copy on the file, this time into the rc1.accepted branch.
>
> $ svn copy --revision {developer's rev}
> svn://zinc/batch/trunk/{developer's path}
> svn://zinc/batch/branches/rc1.test/{developer's path}
>
> Question: Does it matter if it is from rc1.test, would copies of
> copies of copies produce problems in the future?
>
>
> If the test team rejects the change, the tech team undoes that copy.
> I'm assuming that an svn log will pick up the previous revision number
> to roll back to. If not, it's back to the spreadsheet.
>
> $ svn copy --revision {previous rev}
> svn://zinc/batch/trunk/{developer's path}
> svn://zinc/batch/branches/rc1.test/{developer's path}
>
> Question: The svn revert won't work since the prior copy is URL to
> URL, so it's automatically commited, right?
Again, changes aren't ported via 'svn copy', but 'svn merge'.
'svn merge' is also used to revert committed changes. All discussed in
chapter 4.
>
>
> At go live, rc1.accepted is exported to the production box, and all of
> the rc1 branches are deleted.
>
> $ svn delete svn://zinc/batch/branches/rc1.test -m "Removing obsolete
> branch"
>
> $ svn delete svn://zinc/batch/branches/rc1.accept -m "Removing
> obsolete branch"
Yes, this is a nice way of keeping your /branches area clean. The
branches aren't really gone; the directories still exist in history.
But this way, your /branches area only shows *active* branches, which is
nice.
>
> Question: I think that the way that we're using branches is similar to
> how tags are described in the book, so would this make more sense to
> create as tags/ instead of branches/?
Nope, because tags are "frozen" snapshots. Branches are lines of
development that change. So you're doing the right thing, using
branches.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 27 19:03:19 2004