On 9/28/07, Sylvain Viart <sylvain.viart@easyrencontre.com> wrote:
> 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?
$ svn switch http://url/tag/path .
Makes your working copy reflect the state it had when you created the tag.
> And discussing about this seems that I misuse SVN, or I do not make branches
> to work efficiently. I rewrite my proposed svn use:
>
>
> developers use trunk, and commit what ever they need.
> when ready they update part of their changes on the deployment wc (somewhat:
> cd /deploy ; svn up -r myrev or HEAD somefiles)
> if it works as expected, some test are performed on the new code and the wc
> is validated for production
> 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))
> the deployment wc is freed but keep its states (here I block with this
> topic)
> END
> 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.
> 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.
Ouch. This is probably where you're going wrong: you should commit all
changes, even if (slightly) destabilizing, but not all to trunk. If
you want to refactor code (in a destabilizing way), use a branch.
> 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:
Reading your proposed schema and the different arguments you're using
for the way you want to work, I'd say you need to start working with a
small project for some time to figure out what works for you. There's
not one truth.
bye,
Erik.
Received on Fri Sep 28 11:22:50 2007