On Mon, Feb 28, 2011 at 11:13, Christopher D Haakinson <cdhaa...@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.l...@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 > <cdhaa...@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. > >
