Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of andy.levy@gmail.com
 designates 209.85.214.43 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc:content-type;
        b=o1xGTF3KmBPu+KdKI06FK3R8zBccHQUI64X/nCZt0RTDa88wD1sF5Z2/cu2phgrydd
         ZgmUfX0+J7Q0kf96EBgMxLH3hKPQTIq+RIKUl3sqpkLe6g2uFDu+bOmhqfBBo4hVMXnd
         vz1uYt2VhZoiiReN6uHszbZsDkU5eH+dd8EoY=
MIME-Version: 1.0
In-Reply-To: 
 <OF64BE8E94.C25B775A-ON87257845.005891AC-85257845.00591F81@us.ibm.com>
References: 
 <OF06A1BA8C.69FE8BE7-ON87257845.0056C5A1-85257845.00576961@us.ibm.com>
 <AANLkTinjJ-6P+31_W_JserVJaFenC=Ya_h9jf0zAZxoT@mail.gmail.com>
 <OF64BE8E94.C25B775A-ON87257845.005891AC-85257845.00591F81@us.ibm.com>
From: Andy Levy <andy.levy@gmail.com>
Date: Mon, 28 Feb 2011 11:46:59 -0500
Message-ID: <AANLkTinFp=AW+x6MM6qbiYSPW52UNsFuT2fJo7L4VSYC@mail.gmail.com>
Subject: Re: Help with files changed outside of svn
To: Christopher D Haakinson <cdhaakin@us.ibm.com>
Cc: users@subversion.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Feb 28, 2011 at 11:13, Christopher D Haakinson
<cdhaakin@us.ibm.com> wrote:
>
> I mean that I have a working copy of my project under:
> /svn/hooks
>
> This folder gets automatically updated with svn update on every commit with a post-commit hook
> This folder also is "live", meaning that the files here are in use at all times, so nobody will be using this "working copy" as their development copy, it's just there to receive all the newest changes.

If you're getting conflicts in those files when performing an update,
then someone *is* using that working copy. Otherwise, the changes
would be merged without conflict into that working copy.

> The scenario I want to test and know how to handle is when a file in /svn/hooks gets changed outside of svn and these changes never get commited into svn.
>
> I understand what svn is and is not, but the files I will have inside svn will also be available and writable on a network, so I need to know how to handle files that get changed inside my live working folder outside of svn.

Again, "outside/inside svn" has no meaning (or ambiguous meaning) in
this context - please try to find the correct terminology to use here
to remove this ambiguity. It sounds like your workflow is supposed to
be:

1) Hook developer checks out hook scripts from repository to a local WC
2) Make edits
3) Commit changes to hook script
4) Hook scripts are auto-updated in /svn/hooks via a hook.

Result: Nothing should be in /svn/hooks that isn't in the repository.

What appears to be happening is that someone is editing in /svn/hooks
while at the same time someone else (or maybe the same person) is
editing in their own WC. This can generate a conflict when those
changes are committed from one WC and updated into the other.

Solution: lock people out of making changes to /svn/hooks, except via
that hook script that pulls the updates down. You should not get any
conflicts this way.

Alternate solution: Require people to only make changes in /svn/hooks,
and disallow commits from any other location (which would not be easy,
as the hook script does not know where on the client content is being
committed from - you'd have to do some per-user permissions & only
allowed a specific person/group to commit, and trust them to do the
right thing).

> Also is there a way to change what gets written to a file when this occurs? All my scripts get corrupted because of the >>>>>>> and I'd like to at least put a # in front so that it's a commented line and doesn't affect the execution...

No, part of the point of doing this is to make it *very* obvious that
something needs to be fixed. Even if those lines were commented out,
the content between them would likely break your script, or at least
cause unpredictable/undesired behavior.

> Andy Levy ---02/28/2011 11:02:11 AM---On Mon, Feb 28, 2011 at 10:54, Christopher D Haakinson
>
>
> From:
> Andy Levy <andy.levy@gmail.com>
> To:
> Christopher D Haakinson/Raleigh/IBM@IBMUS
> Cc:
> users@subversion.apache.org
> Date:
> 02/28/2011 11:02 AM
> Subject:
> Re: Help with files changed outside of svn
> ________________________________
>
>
> On Mon, Feb 28, 2011 at 10:54, Christopher D Haakinson
> <cdhaakin@us.ibm.com> wrote:
> > I'm fairly new to svn, and I have things set up and running well.
> >
> > I wanted to test out a scenario where a file controlled by svn gets changed
> > outside of svn inside the working copy, and now I'm lost and can't find much
> > help on what to do.
> >
> > Here's my example: I setup the hooks folder as a svn project. Checked it out
> > onto my windows box and made a small change, then committed the changes.
> > Now I went through my command shell and manually changed a file outside of
> > svn.
> > Then I went back to my windows box and editted the same file with a
> > different change.
>
> Do you mean to say that you edited the same file in multiple working
> copes? There is no "outside" svn as svn isn't a program in which you
> edit files, and you can't edit directly in the repository.
>
> > Now the original file contains: ">>>>>>> .r3" at the bottom
> >
> > Also I have some more files inside my working directory too:
> >
> > pre-revprop-change.tmpl
> > pre-revprop-change.tmpl.mine
> > pre-revprop-change.tmpl.r2
> > pre-revprop-change.tmpl.r3
> >
> >
> > Can someone please explain to me:
> >
> > 1) Why does >>>>>>> get put into the bottom of my files?
> > 2) What are the 3 copies of this file for?
>
> You have generated a merge conflict - you've changed the same line(s)
> of the file in 2 different ways.
>
> > 3) And now how do I get these files merged back into one copy with the
> > changes made inside svn included and the changes made outside svn excluded?
>
> You must now resolve the conflicts. See
> http://svnbook.red-bean.com/nightly/en/svn.tour.cycle.html#svn.tour.cycle.resolve
>
> As I said above, there is no "outside vs. inside svn" - you apparently
> have changes made from 2 different working copies. This is a normal
> situation but Subversion cannot handle this for you automatically -
> YOU must tell Subversion which content is correct.
>
>