Re: Copy svn commmits

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.

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

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

I manually copy the file onto the production server - 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.

Short of running a separate repository for production, this seemed to be
the best answer.
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.

- Gavin.

John Peacock wrote:
> Gavin 'Beau' Baumanis wrote:
>
>> @Ryan, I assume that your point is that I would still perform the Merge
>> operation - but into a TAG as opposed to a branch.
>>
>
> No, you don't need to merge at all (unless what you have on trunk isn't
> completely consistent). Normally, you do all of your development on trunk and
> when that is ready to go into production (ALL OF IT, not just some files), then
> you create a tag based on the tip of trunk (otherwise known as HEAD). These
> tags are then read-only (by convention, though you can enforce that by a
> pre-commit hook).
>
>
>> And instead of relying on "revisions" - I would have the naming of the
>> tag to assist with "rolling back" changes made (in error) to the
>> production system.
>>
>
> No, you 'switch' to a tag to put your current best release into production.
> Then when you are ready to move then next release into production, you switch to
> the next tag. Reverting to a previous state is as simple as switching back to
> the prior tag. No merging is involved in this scheme at all.
>
> John
>
>

-- 
Gavin Baumanis
Principal
The Spidernet Web Design
W: http://www.thespidernet.com
E: gavinb_at_thespidernet.com
P: 03 9750-6313 (+61 39750 6313)
M: 0438 545 586 (+61 438 545 586)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org