On 16.07.2005, at 16:01, Alan Knowles wrote:
> 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 ;)
"Client" is a human being? As in, the person for whom you've created
the web site?
> 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.?
I seems to be as though nobody should ever be making changes in the
working copy on the live server. If this client of yours needs to
make changes to the system, then it seems like they should be having
their own working copy, making the changes there, committing them to
the dev server, and then you or an automated process or post-commit
hook can update the copy on the live server.
I'll admit I'm having a hard time visualizing this scenario. In my
work, our clients don't know anything about web site programming,
which is why they come to us to do it for them. So our clients would
not have the slightest bit of access to the repository containing
their site's code. They want something done, they send us an email,
and we do it for them. But perhaps your situation is different.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jul 28 22:15:31 2005