The answers already given address your situation. You've just made it
much more complicated than it needs to be by manually copying things.
Let me see if I can give you examples of how to make it easier...
On Mar 8, 2008, at 00:36, Gavin 'Beau' Baumanis wrote:
> I am betting that I just wasn;t very clear in my original topic...
> but thanks again for the help...
> And let me try again....
>
>
> In the trunk is the working that everyone uses - which is fine...
> Everyone does their own work and test their specific changes in a
> (local to them) testing environment.
> They commit their (pre-locally tested) change back into the trunk.
>
> The trunk is CRONned to the staging server every 15 minutes - where
> integration testing is performed.
So the staging server has a working copy of the trunk and "svn
update" is run every 15 minutes. That's fine...ish. It's could be not
fine in the scenario where you're testing the site, and while you're
testing it, the 15-minute cycle is up and an "svn update" is
automatically performed and now suddenly part of your testing is on a
later revision of the code. Better to know what revision you're
testing throughout the entire test process, so that you can later
promote that specific revision to production.
> If integration testing passes, (on the staging server) then I
> manually copy into the branch the latest copies of file1/file2/
> file3.cfm into /branches/production/customerA
> Commit the changes to the branch.
> The production branch and the trunk have files with matching
> content (despite them being at different revisions)
> Lets assume that the trunk has file1.cfm @ revision 8 and the
> branch has file1.cfm @ revision 9 (due the extra commit into the
> branch - but essentially is file1.cfm @revision 8
So your staging server's working copy is of the trunk at revision 8
and you've tested it and decided that it is good and should be
promoted to production. You simply copy trunk at revision 8 to a new
tag (creating revision 9 probably (but not necessarily -- another
developer may have already committed later revisions; that's ok)):
svn copy $URL/trunk_at_8 $URL/tags/2008030800 -m "Creating tag
2008030800 from trunk r8"
> (let's assume I have edited a file; file1.cfm
> I commit it to the trunk @ revision 10.
> I perform integration testing and find an error - that I didn't
> notice locally.
> I edit file1.cfm and commit to the trunk again.
>
> Let's assume this happens a few times and I now have file1.cfm in
> the trunk at revision 20.
>
> All testing passes and I manually copy file1.cfm into the
> production branch, commit it and have revision 21 in the branch
> (effective rev20 on the trunk).
Instead of manually copying files to the branch, you again create a
new tag from trunk_at_20 (probably creating revision 21):
svn copy $URL/trunk_at_20 $URL/tags/2008030801 -m "Creating tag
2008030801 from trunk r20"
> I manually copy the file onto the production server
Instead, you would also have a working copy on the production server.
You would manually switch that working copy to the new 2008030801
tag, or automate that using the Perl module which was described a few
messages ago.
> - where I now find an issue.
> I want to revert my file on production back to the previous version
> that was on the production server.
> Thus I revert file1.cfm on the production branch back to revision 9
> - and we're back to how we were with respect to files that were on
> the production server.
Simply switch the production working copy back to the 2008030800 tag.
> Short of running a separate repository for production, this seemed
> to be the best answer.
It would be quite difficult to have a separate repository. Subversion
is not designed for sharing code between repositories, only within a
single repository. So multiple repositories are not appropriate for
promoting one project's code from one environment to another.
> I take on-board that since it is a set state of files at production
> - then a tag long the lines of yyymmddXX (xx for serial) is little
> more "normal/expected".
>
> Now my whole original question was is there a convenient way (at
> the moment I manually copy all files between the trunk and branch
> (soon to be tag)) to update the production tag with a range of
> commits attributed to the trunk?
>
> I don;t know if that helps any more... but is the best way I can
> think to explain it for now...
>
> As always, - Thanks for any help you might be able to offer.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-08 08:05:32 CET