The main issue I have is that the user expects import to import everything.
Anyone reading the documentation on import wouldn't guess that import
doesn't import everything. It just isn't safe to assume that the user
doesn't want to import a .so or .pyc file or anything else. I agree that
you generally wouldn't want to do such things, but importing the jdk is a
case in point. Wouldn't it be safer to just let people add their own
extensions to the global-ignores variable and default to nothing?
On Fri, Feb 20, 2009 at 7:44 PM, Ryan Schmidt <
> On Feb 20, 2009, at 12:29, Justin Johnson wrote:
> On Fri, Feb 20, 2009 at 11:58 AM, JJ <eggsgloriouseggs_at_gmail.com> wrote:
>> I currently have the same issue as described in this thread.
>>> I'm trying to import the JDK and all .so files are being quietly excluded
>>> from the import every time. The above thread points to .so files being
>>> included in the default value for global-ignore even though the book doesn't
>>> include it in the list, as can be seen at
>>> My thought is that having default ignore values is a mistake to begin
>>> with. It seems dangerous to me to have a default ignore value that prevents
>>> Subversion from importing certain files and having that default value
>>> quietly documented (ignoring the error in the doc for now) in an obscure
>>> section of the documentation or a config file that they wouldn't necessarily
>>> read for a long time.
>>> Does anyone else agree? Am I missing some important use case that drove
>>> this decision in the first place?
>> More info. Between 1.4.6 and 1.5.0 .so files were added to the default
>> values in http://svn.collab.net/repos/svn/tags/1.5.0/
>> Again my point is that I think these default values are dangerous and that
>> nothing should be ignored by default.
> The fact that .so was added to global-ignores was mentioned on the list
> last week:
> I suppose the reason why Subversion has certain things in the
> global-ignores by default is that it is a best practice to not commit
> certain files. For example, some editors will automatically make backup
> copies of files you edit, but you would not want to check those in, because
> the repository already contains your backups in the form of previous
> revisions. It is also a best practice not to commit files you can recreate
> from other files that are already in the repository. So if you have the
> source code to make a shared library, then it's recommended not to check in
> the compiled shared library itself. Of course you're free to do as you like,
> and certainly there are reasons why you would nevertheless like to check in
> such files. Subversion does not prevent you from "svn add"-ing such files
> and then committing them. Or you can set a different global-ignores
> definition that suits your style of work better.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-23 14:44:54 CET