Hi,
John Peacock a écrit :
> Sylvain Viart wrote:
>
>> It's for deployment purpose.
>>
>> I've a dedicated trunk wc for deployment, and for now it's more that
>> often in mixed version states.
>>
>
> You are really making this much more difficult than it needs to be. A tag is
> merely a copy that represents a collection of files at specific revisions; there
> is *no* requirement that all files must be as of the same revision. For that
> matter, you can make a tag based on an existing mixed-revision working copy ala
>
> svn cp . http://url/path
>
In fact I understand this point very well, my initial question was how
to get all the revision recorded back again in my trunk wc?
And discussing about this seems that I misuse SVN, or I do not make
branches to work efficiently.
I rewrite my proposed svn use:
1. developers use trunk, and commit what ever they need.
2. when ready they update part of their changes on the deployment wc
(somewhat: cd /deploy ; svn up -r myrev or HEAD somefiles)
3. if it works as expected, some test are performed on the new code
and the wc is validated for production
1. the wc is copied into a tags and deployed on production
server based on that new tag (probably a switch or an export
or something equivalent (rsync +filter))
2. the deployment wc is freed but keep its states (here I block
with this topic)
3. END
4. if it doesn't work, the deployment wc may be altered by the
developer testing its code, to match preproduction environment
requirement for example.
* if the changes are slim they are commited in the trunk, they
we go at step 3
* if the changes seems too big, the developer must free the
deployment wc and go back to the DEV aborting its deployment.
5. the deployment is aborted the deployment wc must be reverted to
its previous stable states. somewhat a saved tag, but should be in
the trunk?? same as 3.2, I block here.
> Your method of tweaking the rev of many files in your "trunk_wc" means that
> there is *no* control over those files.
In fact, in the deployment wc they're in mixed revision states and
effectively there's no simple way to switch back to that states.
Another point to mention, is that edition is expected in the deployment
wc. So I need to trac modification in that wc as well.
Another point, I don't want to force commit for deployment purpose if
the deployment should be aborted next...
> If I am understanding your scheme, then I can suggest an alternate one. How
> about I give you the ability to keep any given WC pointing at the most current
> tag [matching a regex], with as much of the tag history maintained as you like
> (so you can roll back to any point in time)? All your developers have to do is
> to create a tag with a predefined (by you) name, and a post-commit script will
> keep that WC in sync automatically.
Seems interesting, but I don't want to to use commit to test all
changes. I prefer to have commit restricted to main changes, not to
deployment test.
> This is particularly good for web site
> developers because it means that there is no need to ever update the production
> server directly - the post-commit script does all of the work for you.
>
I've bring one simple solution to this, but may be not the best, is to
have the wc be on the DEV web server. :-)
Which for me, is better than to have to commit each time you want to
have source online. You can only commit stable code.
> I wrote SVN::Notify::Mirror for this precise purpose. One of the most powerful
> capabilities is to match a commit path based on a regular expression and switch
> a WC to this new path. You shouldn't fear switch, it is very efficient. It
> only updates the files that change between rev A and rev B, so if you have large
> WC's, it will only change those specific files.
>
> Here is my proposed development schema:
>
> 1) All normal development happens on trunk (though you can just as easily use
> branches)
>
> 2) Any testing server you have always tracks trunk using a post-commit script
>
> 3) The production server always tracks the latest tag that matches some regex,
> say RELEASE-YYYYMMDDSEQ, also using the same post-commit script.
>
>
does it mean your developers need to commit all change, each time, to go
from step 1 => 2 ?
Thanks for your suggestions.
I'm still thinking about a nice way of having test and revert on the
preproduction stage.
Sylvain.
Received on Fri Sep 28 09:16:40 2007