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

Re: Issue #1756 -- import doesn't handle svn:eol-style or svn:keywords

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2004-03-09 14:30:52 CET

kfogel@collab.net wrote:
> Julian Foad <julianfoad@btopenworld.com> writes:
>
>>I am voting -1 for this, due to the "repair" of line endings. For
>>the other reasons mentioned below I would have voted "-0".
>>
>>A normal commit, via svn_wc_transmit_text_deltas, does not force
>>repair of inconsistent line endings, but fails with an error. This
>>patch to "import", on the other hand, silently "repairs"
>>inconsistent line endings. I think that is the wrong thing for it
>>to do, as I don't see any reason for it to behave differently from
>>"commit".
>>
>>This patch is on the fuzzy line between fix and enhancement. Lack
>>of this patch only "allows malformed data" in the same way that any
>>commit does if "svn:eol-style" and "svn:keywords" are not as
>>intended. Behaviour without this patch is to preserve the file
>>contents exactly. For these reasons I don't think there is a strong
>>need to put this patch in 1.0.1.
>
> I voted +1 for the change, but still have to say your argument is
> persuasive...
>
> Next question is: does the change belong in 1.1? Do you consider the
> behavior undesirable overall, or just not appropriate for 1.0.1?

I consider the behaviour to be desirable overall, and better than the status quo, but just lacking a simple fix to make it consistent with "commit". Given that fix, it definitely belongs in 1.1, and maybe even in 1.0.1 if other people think it more important than I do. (This fixes one aspect of "import", but I don't like "import" anyway, as there are so many other ways in which it can do what I don't want: add files that I don't want, wrongly guess the binariness of files, etc. I nearly always copy the project into an empty WC and recursive-add it; since I am going to want a WC anyway, this saves the checkout, and gives me the chance to remove unwanted files and adjust the properties before making the first commit.)

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 9 14:29:59 2004

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

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