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

Re: Error handling issue during commit

From: Wayne <wayne_at_zk.com>
Date: Fri, 02 May 2008 11:59:10 -0700

devellison wrote:
> Greetings,
> Looked at the issue tracker and did a quick search here but didn't
> find a reference to this problem, so...
> If you commit multiple files that have not yet been added to the
> repository, the error handling does not always report errors to the
> user and completion may be reported as successful even if it was not.
> Specifically, I have the eol-style:native property set for several
> file types. When I attempt to *add* one or multiple files with a non-
> native EOL style, I receive an error reporting the mismatch - this is
> correct behavior.
> However, if I try to *commit* a group of previously unversioned files
> and one has a mismatch, it appears to add all of the files *up to the
> bad one*, then commit them and report a successful commit. The bad
> file and all files (good or bad) after the error are not committed to
> the repository, and the user is not warned of this.
I believe that I have seen this issue before. It happens with the
subversion command line client as well. I reported in on the subversion
users list but no one seemed to think it was a bug. Maybe the behavior
has changed slightly. When I reported this with the command line client
I saw that the client checked in all files up to and including the file
with inconsistent line endings. *After* checking in the file it would
exit with an error indicating it couldn't continue because the file that
was just checked in needed to be fixed.

I guess the up side is that if you have a bunch of new files with
inconsistent line endings you can check the whole thing in without
actually fixing anything by just re-running the check-in command until
it stops failing ;-)
> I've run into this a couple of times recently migrating a project into
> SVN - one time it was obvious (3 files were committed out of a few
> hundred), but the other time just 4 files from an entire library were
> dropped and I didn't catch the mistake until I committed at a lower
> level and saw unversioned files where there should have been none.
This may be a difference in the way TSVN handles the error. I know that
the command line client actually checked in the first 'bad' file before

To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
Received on 2008-05-02 20:59:24 CEST

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