[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Merge trunk and prod directories without workspace

From: Les Mikesell <lesmikesell_at_gmail.com>
Date: Tue, 17 Mar 2015 21:58:07 -0500

On Tue, Mar 17, 2015 at 9:45 PM, Les Mikesell <lesmikesell_at_gmail.com> wrote:

Sorry - accidentally sent before finished...

> On Tue, Mar 17, 2015 at 8:21 AM, Lathan Bidwell <lathan_at_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
Received on 2015-03-18 04:00:05 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.