[Bf-committers] move prebuilt libs from svn to git?
ray at lazydodo.com
Sat Jun 18 21:15:40 CEST 2022
Except for you just now i don't think anyone is
questioning the need for version control on the
3rd party dependencies. This tree was there long
before i joined the blender project so can't give
any insights on any controversy in creating it.
However whenever this subject (why svn) comes up,
it tends to be one or both of these scenario's
1) svn is giving people a hard time, calling it
"quirky" would be generous, it doesn't recover
nicely whenever it runs into trouble, and with
the large size of the libraries and the slow
download speeds for some people it's just bound
to run into trouble. And these people rightfully
question "Why is it like this?"
2) SVN is old, everything uses git these days
it's the hip and trendy new kid on the block.
they never have these kinds of issues with git!
why is blender being so silly, just use git!
on the other hand, no-one is using pure git to manage
a large collection of binaries since it is just not
designed for this job, in much the same way the
hand basket at your local hardware store is not
designed to pick up that 25kg bag of cement.
git-lfs is one of the proposed solutions, but
also not free of problems  (written by the
maintainer of an different version control
system, be aware of "some" bias there)
Yet another alternative is to go, 3rd party
dependencies are no concern of us, developers
can go obtain/build these on their own. This is
the stance taken by the majority of opensource
projects. And I'll admit, as one of the people
responsible for the contents of this repository
I can't help feeling some envy there, maintaining
the libs and guaranteeing a smooth experience for
developers is *VERY* time consuming. However seeing
new people join the blender project going "building
blender was much easier than I expected, I finished
my small first patch fixing something that had been
bothering me in under a day" negates those feelings
and makes me realize as a project the blender project
is better for everyone by having these libs available.
SVN is what we have and it's mostly working for us
there's alternatives but there's a lot more nuance
to it than "just use X I never have problems with X"
On 2022-06-18 11:24 a.m., Zack Brown wrote:
> Thanks, I appreciate the explanation. It still seems weird. I'm sure the original conversation that led to this particular svn tree must have involved some amount of controversy.
> But at this point in the project's history there's definitely something to be said for "if it ain't broke, don't fix it." Especially with so many amazing blender features in rapid development.
> Be well,
> On Sat, Jun 18, 2022 at 6:45 PM Ray Molenkamp <ray at lazydodo.com> wrote:
> libraries change over time, sometimes they have large api changes
> where we have to do reintegration work into blender.
> Which then leads to, if we have a single folder with libs, what
> do the 2 concurrent LTS releases use? that same lib folder? they
> need major rework to use them, we can't land rework in an lts release
> brand new bugs will likely come with it. option b: well we'll give
> every release their own folder on that shared drive so they won't have
> issues when the libs change.
> wait a minute... we've just reinvented version control :)
> On 2022-06-18 1:04 a.m., Zack Brown wrote:
>> Hi everyone,
>> It's fascinating to see this discussion. It never occurred to me that anyone might continue to prefer svn once git came into existence, and yet here is a sample case, right under my nose! I guess svn is still relevant even after all these years!
>> But actually I'd be curious to know why revision control is used at all in this particular case. We're talking about precompiled binaries, right? That's sort of the poster child for situations where revision control is *not* what one wants, exactly for the reason why git would be a bad choice.
>> Please, could someone explain why the blender project doesn't simply use a dev-accessible shared folder somewhere? I love revision control, but it's only useful if it's useful.
>> Be well,
More information about the Bf-committers