I feel your pain, but I hope that the Subversion NEVER puts a
"--force" switch on commits. 99% of the time, you don't want to commit
changes when the code you've edited is out of date.
So, let me get this straight:
1), You have a checked out version of the code on the "live" server
2). The client modifies this copy, but doesn't check in those changes.
3). Instead, you check in those changes on the "development server"
and update the client (which already had the change).
Why have a Subversion working directory on the client if you're making
the changes over there, but not checking in the changes over there?
There's a script called "svn_load_dirs.pl" that comes with Subversion.
This script will take a copy of a directory tree, and update a
Subversion copy of that tree. It is mainly used for vendor software
updating.
Why not, instead of having a "svn checkout' on the client, an "svn
export". Then use "svn_load_dirs.pl" to copy the client's copy to the
development server's working copy?
Two other quick suggestions:
* If you set your diff and diff3 programs to "/bin/false" or something
that will return a non-zero return code, Subversion won't do any
merges and will let you manually handle them. In this case, you simply
rename the *.mine copy of the file and do "svn resolve". That will
allow Subversion to always take the file from the version you want and
not worry about merging.
* I wonder if "svn switch" might help in this situation. You could
"switch" from your current revision to the "head". I wonder if it will
then accept the changes on the current client without insisting on a
merge? I'll have to give that a try.
On 7/16/05, Alan Knowles <alan@akbkhome.com> wrote:
> Not sure if this is solvable in any cleaner way. but since I could not
> find an answer in the manual/ google I thought I'd see if anyone had
> better ideas.
>
> Scenario:
> Dev server with Copy of code (web site app etc.)
> Live server with copy of code.
>
> We have checked out the current head into both places..
> Client sends email saying can you make this change.. (which is done on
> dev server)
> Meanwhile client makes another change to the live checked out version.
> (something fun like changing all the line breaks ;)
>
> I make the changes to the dev server, check in the changes - then go to
> the live server and realize that the working copy has been modified
> there...
> - since I dont really want to break the live server, I dont want to do a
> update, as it will end up with <<<< merge tags everywhere..
>
> Ideally I want to commit the clients changes and override my own changes
> (which are easier to reproduce..)..
> But commiting the files always gives 'working copy up to date'
>
> ----------------
> Workaround:
> I ended up copying the changed file to the dev server, and committing it
> from there, then doing a svn up on the live server..
>
> but It would have been easier to using a commit --force or something...
> - Have I missed something in the docs? or is there a better way to do
> this.?
>
> Regards
> Alan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
--
--
David Weintraub
qazwart@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jul 18 00:23:32 2005