Is a two step commit possible?

["Kraja, Toni" <To...@bci.tu-dortmund.de>]

Hello,

I am using one computer that is used for developing a web project, then
a server where the web project is running at and a third server that
provides the svn repository folder.

Now it works this way:
First i commit to the second server and then let the first sever update
his own files.


I would like to use svn now this way:

First: if i have worked on a file, commit it to the first server to test
if the project with the current changes is working as excepted.

Second: Commit the changes then to the second server to have a stable
copy on there.


Is there any easy way to change it this way? I except that i have to
announce somehow the first server folder as the repository and then let
the second server do updates if necessary, am i right?

What disturbs me on this idea is, that a problem i have with the way it
works now would still occur: Unnecessary high counting of the revision
number and filling the svn history with too many minor changes that had
to be made for testing.

Best regards

Toni Kraja
 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Is a two step commit possible?

[Blair Zajac <bl...@orcaware.com>]

Kraja, Toni wrote:
> Hello,
> 
> I am using one computer that is used for developing a web project, then
> a server where the web project is running at and a third server that
> provides the svn repository folder.
> 
> Now it works this way:
> First i commit to the second server and then let the first sever update
> his own files.
> 
> 
> I would like to use svn now this way:
> 
> First: if i have worked on a file, commit it to the first server to test
> if the project with the current changes is working as excepted.
> 
> Second: Commit the changes then to the second server to have a stable
> copy on there.
> 
> 
> Is there any easy way to change it this way? I except that i have to
> announce somehow the first server folder as the repository and then let
> the second server do updates if necessary, am i right?
> 
> What disturbs me on this idea is, that a problem i have with the way it
> works now would still occur: Unnecessary high counting of the revision
> number and filling the svn history with too many minor changes that had
> to be made for testing.

You typically set this up using branches instead.  You have a trunk and a qa and 
a production branch.  You do work in trunk and when you want to test it, merge 
all your changes into the qa branch.  The qa branch is checked out on the first 
server.  When you're happy with your changes, you merge them all into the 
production branch.  The production branch is checked out on the production system.

Regards,
Blair

-- 
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
<bl...@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Is a two step commit possible?

[Hilco Wijbenga <hi...@gmail.com>]

On Fri, Oct 31, 2008 at 05:01, Kraja, Toni
<To...@bci.tu-dortmund.de> wrote:
> I would like to use svn now this way:
>
> First: if i have worked on a file, commit it to the first server to test
> if the project with the current changes is working as excepted.
>
> Second: Commit the changes then to the second server to have a stable
> copy on there.

Why would this require another commit? Can't you just use a working
copy on the second server? I would think a simple svn up would do the
trick.

Otherwise, create a second project that uses svn:externals (with a
specific revision number) to link to your actual project. You can then
commit at will to your project but only update the svn:externals link
when you're ready.

> Is there any easy way to change it this way? I except that i have to
> announce somehow the first server folder as the repository and then let
> the second server do updates if necessary, am i right?
>
> What disturbs me on this idea is, that a problem i have with the way it
> works now would still occur: Unnecessary high counting of the revision
> number and filling the svn history with too many minor changes that had
> to be made for testing.

I don't understand the problem. Who cares about the revision number?
And I would think it's the job of an SCM tool to store all those minor
changes? :-)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org