You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Gavin 'Beau' Baumanis <ga...@thespidernet.com> on 2008/03/07 02:55:34 UTC
Copy svn commmits
Hi Everyone,
I have created a branch "/branches/Production"
That I use for the purpose of tracking updates made to the production
system of a web application.
If there is an unexpected error as a result of an update to production I
need to revert to the previous version that was in production.
Consider; 'file1.cfm' may have several revisions made to it before it
actually gets to production.
Without the production branch I would be unable to easily know which of
the revisions for this file was indeed the last one placed into production.
Anyway,
Onto the problem.
Lets assume that I have sequentially committed to the trunk, 20 separate
file updates via 20 separate commits.
All 20 of these commits to the trunk need to be replicated to the
production branch.
Using the above assumptions - Is there a relevant function that will
enable me to do;
copy the "current state" of the 20 files from the past 20 commits, into
a new location, as 1 single commit?
Thanks for any help in advance.... even if that might be "No you can't
do that!"
--
Gavin Baumanis
Principal
The Spidernet Web Design
W: http://www.thespidernet.com
E: gavinb@thespidernet.com
P: 03 9750-6313 (+61 39750 6313)
M: 0438 545 586 (+61 438 545 586)
Re: Copy svn commmits
Posted by Ryan Schmidt <su...@ryandesign.com>.
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@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@20 (probably creating revision 21):
svn copy $URL/trunk@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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Copy svn commmits
Posted by Gavin 'Beau' Baumanis <ga...@thespidernet.com>.
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@thespidernet.com
P: 03 9750-6313 (+61 39750 6313)
M: 0438 545 586 (+61 438 545 586)
RE: Re: Copy svn commmits
Posted by "Menschel, Bob [HDS]" <Bo...@hdsupply.com>.
The situation I'm migrating to is quite similar to Gavin's, and I'd like
to run these ideas by the group. I'm just now developing the repository
and working copies (migrating from an ancient SCCS system of source code
change control).
We're a retail organization. We occasionally have large projects with
full life cycle planning, but more often we deal with small atomic
changes to our production systems, such as: Add a new report version
415.7 to application 415, similar to version 415.6 but adds a new column
and sorts in a different sequence (requires an SQL extract, a report
generator, and a shell script that ties them together).
Planned repository structure:
/trunk - all primary development happens here
/qa - pre-production validation
/prod - approved production systems
/prod/prod-yyyymmdd-rev tags - updated production systems
Process:
All development is done through whatever combination of working copies
makes sense to the developers. They all create their working copies and
update from trunk. As each atomic change is completed, it's tested in
this environment, and then committed to trunk.
After the change is completed, tested, committed, it's passed to the Q/A
team. The Q/A team <svn merge>s the specific trunk changes to the QA
working copy, and does their Q/A testing against that working copy. If
the Q/A fails, they <svn revert> the change and report the failure to
the developers.
If the Q/A succeeds, the Q/A team <svn commit>s this change to the /qa
branch. This commit's revision number becomes our production deployment
control number.
The change is submitted to production deployment, and the deployment
team does the following:
A) Create a /prod/prod-yyyymmdd-rev tag
B) Switch the production working copy to point to the new tag
C) Update the production working copy from the new tag.
Will that work?
Bob Menschel
Senior Systems Analyst
HD Supply, Repair & Remodel
3222 Winona Way # 201
North Highlands, CA 95660
Phone: 916-331-5934 x155
Fax: 866-504-2857
email: Bob.Menschel@hdsupply.com
website: http://www.hdsupplyrepairandremodel.com
One Team, Driving Customer Success and Value Creation
-----Original Message-----
From: John Peacock [mailto:john.peacock@havurah-software.org]
Sent: Friday, March 07, 2008 4:23 AM
To: Gavin 'Beau' Baumanis
Cc: Ryan Schmidt; Andy Levy; Subversion Users
Subject: Re: Copy svn commmits
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Copy svn commmits
Posted by John Peacock <jo...@havurah-software.org>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Copy svn commmits
Posted by Gavin 'Beau' Baumanis <ga...@thespidernet.com>.
Thanks to you all for your replies.
@Ryan, I assume that your point is that I would still perform the Merge
operation - but into a TAG as opposed to a branch.
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.
Despite having used SVN for several years now - I have never used merge
or path etc.
I always did these process by hand.... but though it about time I
learned a more efficient - less "human" method.
Thanks again!
John Peacock wrote:
> Ryan Schmidt wrote:
>
>> Different answer: I would have said what you're describing is a tag, not
>> a branch. Make a new tag, including a version number or the date or the
>> revision or some unique identifier in the tag name (e.g.
>> /tags/production-20080306).
>>
>
> Yes, but you should account for multiple tags generated per day, so add a
> serialization number, e.g. /tags/production-2008030501.
>
> NOTE that SVN::Notify::Mirror has explicit support for switching a remote
> working copy to a new tag (that matches a regex) as a post-commit (i.e. 100%
> automated)...
>
> John
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
--
Gavin Baumanis
Principal
The Spidernet Web Design
W: http://www.thespidernet.com
E: gavinb@thespidernet.com
P: 03 9750-6313 (+61 39750 6313)
M: 0438 545 586 (+61 438 545 586)
Re: Copy svn commmits
Posted by John Peacock <jo...@havurah-software.org>.
Ryan Schmidt wrote:
> Different answer: I would have said what you're describing is a tag, not
> a branch. Make a new tag, including a version number or the date or the
> revision or some unique identifier in the tag name (e.g.
> /tags/production-20080306).
Yes, but you should account for multiple tags generated per day, so add a
serialization number, e.g. /tags/production-2008030501.
NOTE that SVN::Notify::Mirror has explicit support for switching a remote
working copy to a new tag (that matches a regex) as a post-commit (i.e. 100%
automated)...
John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Copy svn commmits
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 6, 2008, at 21:53, Andy Levy wrote:
> On Thu, Mar 6, 2008 at 9:55 PM, Gavin 'Beau' Baumanis wrote:
>
>> I have created a branch "/branches/Production"
>> That I use for the purpose of tracking updates made to the
>> production
>> system of a web application.
>>
>> If there is an unexpected error as a result of an update to
>> production I
>> need to revert to the previous version that was in production.
>>
>> Consider; 'file1.cfm' may have several revisions made to it
>> before it
>> actually gets to production.
>> Without the production branch I would be unable to easily know
>> which of the
>> revisions for this file was indeed the last one placed into
>> production.
>>
>> Anyway,
>> Onto the problem.
>> Lets assume that I have sequentially committed to the trunk, 20
>> separate
>> file updates via 20 separate commits.
>> All 20 of these commits to the trunk need to be replicated to the
>> production branch.
>>
>> Using the above assumptions - Is there a relevant function that
>> will enable
>> me to do;
>> copy the "current state" of the 20 files from the past 20
>> commits, into a
>> new location, as 1 single commit?
>
> You want to perform a merge.
> http://svnbook.red-bean.com/en/1.4/svn.branchmerge.copychanges.html
Different answer: I would have said what you're describing is a tag,
not a branch. Make a new tag, including a version number or the date
or the revision or some unique identifier in the tag name (e.g. /tags/
production-20080306). In your production working copy, instead of
checking out /branches/Production and then later running "svn
update", you run "svn switch $REPO/tags/production-20080306". If it's
necessary to revert your production system to the previous version,
simply "svn switch $REPO/tags/production-20080305" (if for example
you had made a tag yesterday that you wanted to revert to).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Copy svn commmits
Posted by Andy Levy <an...@gmail.com>.
On Thu, Mar 6, 2008 at 9:55 PM, Gavin 'Beau' Baumanis
<ga...@thespidernet.com> wrote:
>
> Hi Everyone,
>
> I have created a branch "/branches/Production"
> That I use for the purpose of tracking updates made to the production
> system of a web application.
>
> If there is an unexpected error as a result of an update to production I
> need to revert to the previous version that was in production.
>
> Consider; 'file1.cfm' may have several revisions made to it before it
> actually gets to production.
> Without the production branch I would be unable to easily know which of the
> revisions for this file was indeed the last one placed into production.
>
> Anyway,
> Onto the problem.
> Lets assume that I have sequentially committed to the trunk, 20 separate
> file updates via 20 separate commits.
> All 20 of these commits to the trunk need to be replicated to the
> production branch.
>
> Using the above assumptions - Is there a relevant function that will enable
> me to do;
> copy the "current state" of the 20 files from the past 20 commits, into a
> new location, as 1 single commit?
You want to perform a merge.
http://svnbook.red-bean.com/en/1.4/svn.branchmerge.copychanges.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org