[PD-dev] renaming /import to /vendor
Hans-Christoph Steiner
hans at eds.org
Mon Feb 18 01:53:20 CET 2008
On Feb 17, 2008, at 4:51 AM, zmoelnig at iem.at wrote:
> Quoting Hans-Christoph Steiner <hans at eds.org>:
>>
>> The name is pretty arbitrary. But if we use /vendor, then when
>> someone reads the docs on how to use "Vendor Branches", then our
>> setup will match the docs. That's worth something, especially over
>> some arbitrary name that is not documented anywhere or commonly used.
>
> i don't fully see the bonus of what you are trying to explain here.
> personally, i have never seen either an "import" or a "vendor" branch
> in any other svn-repository yet.
> this doesn't mean that such a directory doesn't make sense (else i
> wouldn't have created one :-))
> however, i think that anybody who sees the 4 directories in the root,
> will understand both "vendor" and "import".
> i have chosen "import", since most of the directories in there are
> really only the initial commits that were then developed on
> sourceforge rather than imports of upstream "vendor" releases (which
> are totally unrelated to the development of pure-data (externals),
> e.g. the apple HID stuff);
> i though that "vendor" would be confusing, and that it would be
> nonsense to provide _both_ "vendor" and "import".
> and i did not want to delete the import tags/branches entirely (though
> probably this would have been the best idea)
>
> and finally: we don't have any "calc" directories in our project (even
> though this is mentioned quite often in the docs).
>
>
> but really, hans, if you feel you can sleep better with a "vendor"
> directory, go on an rename it: you are probably the only one who is
> really using it, so why not fit it to your needs?
Ok, it's done.
.hc
------------------------------------------------------------------------
----
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne
More information about the Pd-dev
mailing list