[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: commercial support/training on SVN for Windows?

From: Andy Levy <andy.levy_at_gmail.com>
Date: Wed, 20 Aug 2008 07:07:22 -0400

On Tue, Aug 19, 2008 at 23:20, phpdoc <schmad_at_gmail.com> wrote:
> I've used CVS and SVN everyday for years on Mac and Linux, but I'm
> finding myself frustrated by TortoiseSVN on Windows. Is there a
> company (or individual) who can provide support for TortoiseSVN? My
> biggest problem seems to be that on the Windows server, every single
> file generates a conflict if a change is made locally, even if that
> change doesn't overlap the change made remotely. I think this is a
> line breaks issue (always fun), but I don't know how to fix this,
> short of committing every single file with \n or Windows line breaks.

Set the svn:eol-style property on those files to "native". No need to
pay for support - this is covered in the manual.

> Additionally, I'd love it if I could pay someone to enhance SVN. I
> would kill for the option to svn update without generating conflict
> markers. If running svn update with this option, I would prefer it if
> files with conflicts were simply ignored and everything else updated.
> We deploy our PHP-based software using SVN. We then install an
> automated script which runs svn update every night to install bug
> fixes. However, the conflict markers can bring down a live site if
> we've made a tweak that conflicts with something else that's
> committed.

There should never be conflicts if you started from a working copy and
didn't make changes to that working copy. Why are you getting these
conflicts? If you're tweaking the WC after putting it into production,
why are those tweaks not getting back into your repository? This is a
major gap in the auditablilty of your system and kills your chances at
having a correctly repeatable process.

Subversion *can't* "ignore" conflicts because it doesn't know and
shouldn't attempt to guess at the impact of doing so.

Requests to make changes to Subversion's design need to start on the
Subversion Developers mailing list with a good design document and a
compelling use case that will convince the core group that it should
be done in the first place.

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-20 13:07:32 CEST

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.