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

Re: EOL bytes breaking compare with... on windows

From: Brock Janiczak <brockj_eclipse_at_ihug.com.au>
Date: 2004-07-14 07:30:08 CEST

I scrubbed my local project and the problem only shows up for the base
revision now (this is a good thing).
It looks like the base copy is stored EXACTLY as the server stored it
and it is the responsibility of the client to do conversions (i assume
even keyword substitution).

There is a workaround in the svnClientAdapter which is directly reading
the base file and should be removed (patch attached) as javahl is
supposed to get the contents (and does now). However, javahl is just
reading the file too! We should see if the svn guys are willing to fix
this for us as it doesn't match the way every other type of revision is
handled (ie it should mimick what is done in svn_client_cat).


(revision 747)
(working copy)
@@ -911,19 +911,6 @@
                                 + target);
- if (revision.equals(SVNRevision.BASE)) {
- // svn should not contact the repository when we want
to get base
- // file but it does.
- // Until this is corrected, we get the file directly if
we can
- File file = new
- try {
- FileInputStream in = new FileInputStream(file);
- return in;
- } catch (FileNotFoundException e) {
- // we do nothing, we will use svnClient.fileContent
- }
- }
             byte[] contents = svnClient.fileContent(target,
             InputStream input = new ByteArrayInputStream(contents);
             return input;

Brock Janiczak wrote:

> Hi All,
> Looks like the compare with functionality does work as well as i first
> thought :)
> SVN is sending the contents of the files back in unix format causing
> windows machines to detect the entire file as changed. The
> svn:eol-style property is supposed to do this for you, but it appears
> if it isn't... perhaps it is done in the svn client, not the libraries?
> It worked for me because i use a local repo for testing (http is far
> too slow to be useful).
> Should we add a workaround in the javahl client adapter?
> Cheers,
> Brock
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail: dev-help@subclipse.tigris.org
Received on Wed Jul 14 15:30:08 2004

This is an archived mail posted to the Subclipse Dev mailing list.