Den tors 28 okt. 2021 kl 16:39 skrev Nathan Hartman < hartman.nat...@gmail.com>:
> On Thu, Oct 28, 2021 at 3:47 AM Justin MASSIOT | Zentek > <justin.mass...@zentek.fr> wrote: > > > > Luke, > > > > If the 3D models are "source" files, then I personally approve to put > those files into a Subversion repo. That's what I do everyday with > Electronic engineering CAD files. > > By the way, don't forget you may not be able to "diff" between two > versions of a file. If not, you lose one the main strength of a Version > control system: doing even a small rollback may become a pain... Plus if > you can't diff, you probably can't merge either! I encourage you to use > locks to avoid any form of conflicts. The "needs-lock" property can be > useful. > > > > As for the project status, I don't know anything but I would be curious > to get the developers' point of view. > > > This sounds similar to our use case at $dayjob, where we have been > using SVN since 2007 to house various types of assets, not just > source code. > > Yes, you can't diff and merge binary assets, but that would be true > whether you use a version control system or not. But you do benefit > from having older versions in case you need more than the "undo" of > whatever application creates those files, and you have a log of who > committed each file and when. If you can get your users to write > *helpful* log messages, that's even better. > > Before we adopted SVN, we actually first looked at Git because it > seemed very popular even in those early days, but ultimately we > decided on SVN because it is much more suitable for us, partly > because non-software-developer users are able to understand it and > partly because it's better at housing non-source-code assets, like > CAD, EDA, artwork, documents, etc. Distributed systems like Git rely > upon being able to fork and merge, which you can't do with non- > source-code assets. > This was also my arguments for choosing SVN (also much based on the TortoiseSVN client, we're a strictly Windows shop). I also needed the ability to checkout a specific subfolder of the repository (we need about 7 such checkouts spread in a directory tree that has a non-standardised layout) without cloning everything in each location. Regarding the project's viability going forward, my point of view is > that like all open source projects, it ultimately depends upon > whether those who benefit from it are willing to give back in some > way; not necessarily financially, but rather in terms of helping in > any way that one is willing and able to, whether it's documentation, > fixing bugs, developing features, testing, or whatever. I'm here > because Subversion is important to me both professionally and > personally. > +1 to this. Kind regards, Daniel
