subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Mikesell <lesmikes...@gmail.com>
Subject Re: Merge trunk and prod directories without workspace
Date Wed, 18 Mar 2015 02:58:07 GMT
On Tue, Mar 17, 2015 at 9:45 PM, Les Mikesell <lesmikesell@gmail.com> wrote:

Sorry - accidentally sent before finished...

> On Tue, Mar 17, 2015 at 8:21 AM, Lathan Bidwell <lathan@andrews.edu> wrote:
>>
>>>
>> Also, these publishes are not like putting out a full release of a software
>> package. The entire branch is a website for a university. We never publish
>> everything at the same time. So, I'm not sure how I could implement a useful
>> TAG every time someone decided to publish a subfolder or index.html file.
>>
>
> If the sections are independent subdirectories, you might want to
> manage them independently.
>>>
>
>>> > The problem with using switch is its hard to know where your production
>>> > branch is, and quite easy to accidentally svn update -r HEAD and
>>> > accidentally deploy things.
>>>
>>> It's a matter of workflow.  I don't see why it isn't just as easy to
>>> deploy by incorrectly publishing something to your branch head.
>>
>>
>> The difference is, if you publish something to the branch head, there is a
>> revision that you see in a log, and could revert.
>>
>> if my prod checkout has a bunch of folders each switched to a different
>> revision, if I lose that filesystem and have to recheck out that workspace
>> I've lost all information about what is published.
>
> Except for special cases where you've reverted that would normally be
> your latest release tag. But, with a workflow of publishing by
> tracking tags you would probably track the tag names with some
> process, maybe logging who approved it and when.
>
>> if I copy my entire 250 gig branch, is SVN going to deduplicate that
>> internally and not need more disk?
>
> Svn copies are very cheap. Probably much more so than a merge that
> ends up not being an exact copy of an ancestor revision.
>
>> Most of my publishes happen on subfolders of the full tree, so basically
>> every folder / file could have a different publsh status: incoming add,
>> incoming update, incoming delete. with different revisions.
>>
>> file     trunk rev     prod rev
>> /a/b/c    5000        4850    incoming update
>> /1/2/3    2000       2001     up to date
>> /x/y/z    9000        7438    incoming update
>> /x/y/z/index.html   8000     8001    up to date

So only one outstanding change (set) is possible?

>>> Do you mean diffs against trunk/HEAD?  That should be the same
>>> regardless of the workspace url.
>>>
>> What I currently do is compare the rev number from the prod branch and the
>> trunk branch for an item, and if there are newer trunk revisions, then I
>> show the user that this file has incoming updates.

That would not be much different if your published copy was a tag.

>> My preview runs off my trunk branch, so when they preview they see most up
>> to date (albeit unpublished) version.

Where are the edits/commits happening?  If they are not made on the
preview system, I don't think it would change much to do a merge from
trunk into the previous production workspace there, and publish by
committing to production.

-- 
  Les Mikesell
    lesmikesell@gmail.com

Mime
View raw message