On Thu, Aug 21, 2008 at 22:32, phpdoc <schmad_at_gmail.com> wrote:
>> If you are making direct (manual) modifications on the
>> server and then using SVN for syncing the changes then you are bound
>> to get problems.
>
> That's exactly the issue. Usually, no changes have been made on the
> server. However, on one particularly-bad instance, one developer
> committed a change to config.inc.php. Of course, every single working
> copy had local changes in config.inc.php.
See http://subversion.tigris.org/faq.html#ignore-commit for a way to avoid this.
> While we'll never make that
> mistake again, it would still be nice to be able to make changes to a
> local working copy, and not have to worry about future conflict
> markers showing up in one file if we do an SVN update on the entire
> working copy.
You won't get conflict markers if you don't do what led you into this
situation in the first place.
> Of course, this wouldn't be a problem if the working copies weren't modified.
So don't do it. You need to tighten up access control on your server
and your promotion process so that it *can't* happen - not try to bend
Subversion to work with your potentially broken process.
> However, the point of open-
> source is that the end-user can modify the software. We just want an
> option when updating a working copy to not update files with local
> changes.
You're free to code it, as it's all open source as you've noted.
You'll have to present a compelling argument to the Subversion
developers (this is done in the SVN libraries, not in TSVN) if you
want to see it implemented in the official version.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
Received on 2008-08-22 05:16:04 CEST