On Mon, Mar 16, 2015 at 5:15 PM, <jblist_at_icloud.com> wrote:
>
> On Mar 16, 2015, at 2:04 PM, Lathan Bidwell <lathan_at_andrews.edu> wrote:
>
>
>
> On Mon, Mar 16, 2015 at 4:44 PM, Les Mikesell <lesmikesell_at_gmail.com>
> wrote:
>
>> On Mon, Mar 16, 2015 at 3:16 PM, Lathan Bidwell <lathan_at_andrews.edu>
>> wrote:
>> >
>> >>
>> >> > I have a content management system running on top of SVN. My web
>> servers
>> >> > run a post commit hook that does svn update off of svnlook after
>> every
>> >> > commit.
>> >> >
>> >> > I currently have a "Publish" operation which I implement by doing svn
>> >> > delete $prod_url && svn cp $trunk_url $prod_url. (both repo urls)
>> >> >
>> >> > This causes problems because the post commit hook triggers a delete
>> of
>> >> > the folder on my production web server, and then sometimes takes
>> longer to
>> >> > re-download all the content (some folders have some decent media,
>> about
>> >> > 15-30 gig).
>>
>> Don't you really want to just 'svn switch' your production workspace
>> to the new production target url instead of deleting and checking out
>> again? As long as the content shares ancestry it should just move the
>> differences.
>>
>> --
>> Les Mikesell
>> lesmikesell_at_gmail.com
>>
>> The copy and delete is not ideal. What I am really trying to do is deploy
> the version of the trunk branch to the production branch.
>
> I am not changing my production target url. I am trying to send new
> changes from trunk to prod, while keeping trunk as a separate branch.
>
> Before and after a "publish" action, there will still be those 2 branches:
> /trunk/blah
> /prod/blah
>
> They just happen to have the same content until someone makes new changes
> to /trunk/blah/.
>
> Publish should make the /prod/ be the same as the /trunk/ while keeping
> them separate enough to make changes to /trunk/ and not touch /prod/ (until
> the next publish).
>
> I need to be able to stage changes and preview them (preview server runs
> off the /trunk/ branch).
>
> Lathan
>
>
> In Git, this would involve simply moving a branch pointer to the new
> commit. With SVN, you only have two options: 1) merge the changes that
> occurred in trunk into prod, which probably could get messsy, or 2) delete
> prod and copy trunk to a new prod.
>
> The delete/copy is the only option you have if trunk and prod have no
> common ancestry.
>
> Another alternative would be to use "export" from trunk and store your
> production code snapshot into a tarball that is "released" and archived
> outside of SVN entirely. (e.g. burn to DVD).
>
The prod branch is only updated by copying from trunk, so they do share
ancestry.
I have concerns about 2 things:
1) I don't have the disk / time to download/ ... to checkout the folder I
am publishing
2) If files are deleted in trunk, then trunk is merged into prod, I need to
be 100% sure that a theirs-conflict will ensure that prod is the same as
trunk, not that prod has some of the old version still left, files that
were deleted in trunk, ....
Received on 2015-03-16 22:21:39 CET