subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lathan Bidwell <lat...@andrews.edu>
Subject Re: Merge trunk and prod directories without workspace
Date Fri, 20 Mar 2015 14:14:47 GMT
On Tue, Mar 17, 2015 at 10:58 PM, Les Mikesell <lesmikesell@gmail.com>
wrote:

> 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?
>

a Publish action  operates on 1 file or folder at once.

>
> >>> 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.
>
most of the commits are using direct repository actions. There are a couple
actions that do a sparse checkout for an action.

>
> --
>   Les Mikesell
>     lesmikesell@gmail.com
>

Mime
View raw message