Re: Compression Question
When compression is enabled at the SVN level, what exactly does it compress? Does it just compress the original file content and the deltas? > On Dec 14, 2021, at 8:44 AM, Mark Phippard wrote: > > On Mon, Dec 13, 2021 at 2:31 PM Luke Mauldin wrote: >> >> From reading the documentation, I can see that Subversion 1.14 supports both >> zlib and lz4 compression. I am running Subversion on FreeBSD 13.X on ZFS >> which supports native zstd compression. Some of the repos I host are >> relatively large (60K revisions and 60GB+) and I am wondering what >> combination will give me the best performance? Currently, I have Subversion >> compression disabled and ZFS with zstd compression enabled. In this setup, >> ZFS reports a compression ratio of 1.69X. I would think if Subversion >> natively supported ZSTD compression that would be best but since it does >> not, I just wanted to see if anyone had recommendations? >> > > I think what you are already doing is the best option. This should > give you the best performance. It would be of little value (for you) > if Subversion provided zstd compression since it is being done at the > file system layer. > > Mark
Compression Question
From reading the documentation, I can see that Subversion 1.14 supports both zlib and lz4 compression. I am running Subversion on FreeBSD 13.X on ZFS which supports native zstd compression. Some of the repos I host are relatively large (60K revisions and 60GB+) and I am wondering what combination will give me the best performance? Currently, I have Subversion compression disabled and ZFS with zstd compression enabled. In this setup, ZFS reports a compression ratio of 1.69X. I would think if Subversion natively supported ZSTD compression that would be best but since it does not, I just wanted to see if anyone had recommendations? Luke
Re: ASF Subversion version
Thank you for the information. I am hopeful that one of the outcomes the log4j
situation is that ASF project funding would be increased but I suspect that
thinking is naive. Companies have little incentive to invest in something that
“works well enough”. I too work for a company that has substantial subversion
usage but will not support any development on it.
We are a bit of a unique situation because we have a monorepo with 30-40
different subprojects and the different subprojects have files with the same
name (go.mod, cargo.toml, some .hcl files and some others) that have very
similar or identical content. Originally we had that repo in git but the
combination of so many identically named files with similar/identical content
really messed with things like “git log —follow” and generally the file level
tracking of git since of course git just cares about the tree/blobs and not the
files. We ran tests and subversion 1.14 handled those scenarios substantially
better than git since subversion does track files. We investigated fossil but
it seems to be mostly driven by one person and doesn’t have even the subversion
level of community support.
I hope that subversion continues to be around and thrive for a long time
because even though git “won” the vcs war, I think that subversion does still
have some advantages in a centralized corporate environment.
> On Dec 13, 2021, at 10:24 AM, Nathan Hartman wrote:
>
> On Mon, Dec 13, 2021 at 10:37 AM Stefan Sperling wrote:
>>
>>> On Mon, Dec 13, 2021 at 07:14:46AM -0600, Luke Mauldin wrote:
>>> It looks like the stashing functionality is still experimental. Do you
>>> think there will be more funding in the future to complete it or do you
>>> think it may remain unfinished for a long period of time?
>>>
>>
>> I do not know any specifics about the funding arragements that were
>> made for the staging feature. What I do know is what anyone can tell
>> from public records such as our mailing list archives and in our commit
>> history. Julian, like many others, is working in other jobs nowadays and
>> has not actively contributed much to SVN during the last year or so.
>>
>> I suspect there are still some developers who would be open to the idea
>> of returning to continue working on in-progress features if they could
>> put food on the table in return. A simple fact is that any altruism
>> these people have spent over years in order to provide this tool to
>> communities and companies has largely run dry by now. While SVN grew
>> up because many of its developers were on paid time since 2000, many
>> were also willing to invest some of their free time to help out because
>> this was a fun and challenging project to work on.
>>
>> But not many can afford to do such work in their free time forever, given
>> the complexity of the subject matter, the expectations of quality that
>> need to be met, and the fact that most users are now businesses which
>> simply use SVN because it does not cost them a cent compared to similar
>> proprietary offerings which are usually very expensive. I know this
>> because over the course of about a decade I have helped many such
>> companies move over to SVN from such platforms, and SVN works so well
>> for many of them that most do not even see a need for a paid support
>> contract to get help in case things go wrong. I have seen people in
>> companies who wanted to pitch such things to their bosses but found
>> themselves in a difficult spot when trying to justify a budget for
>> SVN tooling ("wait, did we not just got rid of ClearCase in order
>> to save such costs...?")
>>
>> And naturally, the longer people have moved on with their lives,
>> the less interest they will have in returning to past projects.
>
>
> That leaves us as a community-driven project, and while I agree that
> the codebase is complex and quality matters (hey, we all keep crucial
> information in this thing!) that should not be a deterrent to anyone
> interested in getting involved.
>
> We have a gigantic pool of users worldwide who depend on Subversion
> and for whom other software isn't the right fit, and we need help with
> many different skill areas besides coding, including translations,
> documentation, testing, improving the website, bug triaging, etc.,
> etc. Every little bit of help from each person counts and benefits
> everyone, and if each person did just a little bit, it would make a
> huge difference. It's like everyone putting a flower pot on their
> windowsill. Soon the whole city looks nicer.
>
> Cheers,
> Nathan
Re: ASF Subversion version
It looks like the stashing functionality is still experimental. Do you think there will be more funding in the future to complete it or do you think it may remain unfinished for a long period of time? Luke > On Dec 13, 2021, at 2:42 AM, Stefan Sperling wrote: > > On Sun, Dec 12, 2021 at 07:21:44PM -0600, Luke Mauldin wrote: >> That really is unfortunate to hear about the lack of funding. I see in the >> past few years there has been a lot of work done on the conflict resolver in >> version 10 and multiple stash implementations in versions 11+. Are those >> efforts being driven by people just working on it in their “spare time”? >> > > Those efforts were funded while development on was on-going.
Re: ASF Subversion version
That really is unfortunate to hear about the lack of funding. I see in the past few years there has been a lot of work done on the conflict resolver in version 10 and multiple stash implementations in versions 11+. Are those efforts being driven by people just working on it in their “spare time”? Luke > On Dec 11, 2021, at 10:21 AM, Stefan Sperling wrote: > > On Sat, Dec 11, 2021 at 06:59:31AM -0600, Luke Mauldin wrote: >> Does the subversion project receive any funding from the ASF to hire >> professional developers to complete more complex tasks or is development 100% >> community driven and supported? > > The ASF does not pay anyone for development. I think this is an unfortunate > situation because many ASF projects slowly die off as funding dries up. > I believe the ASF is unlikely to change this long-standing practice, even > though there are other open source foundations which fund developers. > The FreeBSD and OpenBSD foundations pay some development (see their > financial reports), and apparently a new PHP foundataion is starting up > with the sole purpose of funding PHP developers. > > In the past many SVN developers were employed by companies who ran with > business models related to Subversion. This is the funding model the ASF > is promoting. However, as of a few years ago most such companies changed > direction and are no longer employing any SVN developers. Many people have > moved on as a result and are no longer active. > > (Disclaimer: I still receive a small amount of indirect SVN-related funding > via elego's SVN customer support. I occasionally use some of this time > to work on various things in Subversion, even though this budget is not > intended to fund development beyond customer-specific issues which can > only be fixed in the code base. And it is not enough to cover complex tasks.)
Re: ASF Subversion version
Does the subversion project receive any funding from the ASF to hire professional developers to complete more complex tasks or is development 100% community driven and supported? > On Dec 11, 2021, at 4:10 AM, Daniel Sahlberg > wrote: > > > > > Den lör 11 dec. 2021 10:54Bo Berglund skrev: >> On Fri, 10 Dec 2021 07:59:02 -0600, Luke Mauldin >> wrote: >> >> >Gotcha, thank you. >> > >> >> On Dec 10, 2021, at 7:14 AM, Mark Phippard wrote: >> >> >> >> ?On Fri, Dec 10, 2021 at 8:12 AM Luke Mauldin >> >> wrote: >> >>> >> >>> I noticed that the ASF is still running Subversion 1.9.x which was >> >>> released quite a few years ago. Does anyone know why they haven’t at >> >>> least upgraded to the 10.x LTS release which itself is over 2 years old >> >>> at this point? >> >> >> >> ASF Infra uses the package provided by the Linux distro they are using >> >> rather than building and maintaining their own package. >> >> >> >> Why is a constrruction company involved in Subversion? >> >> http://www.asfinfrastructure.com/about-us.php >> >> Strange > > > ASF Infra is the group within Apache Software Foundation that is managing the > infrastructure, ie servers and network. > > Kind regards > Daniel
Re: ASF Subversion version
Gotcha, thank you. > On Dec 10, 2021, at 7:14 AM, Mark Phippard wrote: > > On Fri, Dec 10, 2021 at 8:12 AM Luke Mauldin wrote: >> >> I noticed that the ASF is still running Subversion 1.9.x which was released >> quite a few years ago. Does anyone know why they haven’t at least upgraded >> to the 10.x LTS release which itself is over 2 years old at this point? > > ASF Infra uses the package provided by the Linux distro they are using > rather than building and maintaining their own package. > > Mark
ASF Subversion version
I noticed that the ASF is still running Subversion 1.9.x which was released quite a few years ago. Does anyone know why they haven’t at least upgraded to the 10.x LTS release which itself is over 2 years old at this point? Luke
Re: svndumpfilter: finding source commit for error?
Did this problematic commit occur due to a bug at the time in Subversion or a user error? Luke > On Dec 9, 2021, at 12:47 PM, Stefan Sperling wrote: > > On Thu, Dec 09, 2021 at 06:29:14PM +, Kristofer wrote: >> Hi Stefan and thanks for the hints. Then I need to line up a lot of >> arguments, right? There's no "read from file" option that I can see. I'll try >> that on the next failure, if I get one *fingers crossed* > > Indeed, the list of path prefixes must be passed on the command line. > Support for reading them from a file is not implemented, unfortunately. > >> Btw, I also have this really silly commit sequence where someone managed to >> delete the entire branches/ directory followed by a commit that brings it >> back (not sure if the commiter used a proper reverse-merge or a copy). I >> haven't understood if that can be "fixed" with svndumpfilter or if there's >> some other way to do it. Those two are basically a null operation, but it >> messes with things like "log --stop-on-copy" > > I don't think there is an easy way to fix that via dump/load once other > commits have been stacked on top. Any newer commit might refer to data > stored in the problematic commit, due to deltification and other meta-data > relationships between revisions. Copies in particular refer to node-rev-IDs > which are generally hidden from the user, but which can be seen in the dump > file, and which are not supposed to be changed. > > There is a commit in Subversion's own trunk history which unfortunately > did exactly the same thing. But it is water under the bridge at this point. > People rarely have a need to go far enough back in history to cross it.
Re: Full text search
We have hound setup and it is nice but it only indexes the HEAD commit and so it isn’t useful for searching history. > On Nov 29, 2021, at 5:30 PM, Mark Phippard wrote: > > On Mon, Nov 29, 2021 at 10:19 AM Luke Mauldin wrote: >> >> I saw the —search argument but that only searches commit metadata. I would >> like to do a search of the changed text of the files in the commit. > > Ah, I missed that in your original post. I would suggest using a code > search tool like OpenGrok or Hound: > > https://github.com/oracle/opengrok/wiki/How-to-setup-OpenGrok > https://github.com/hound-search/hound > > Mark
Re: Full text search
I saw the —search argument but that only searches commit metadata. I would like to do a search of the changed text of the files in the commit. > On Nov 29, 2021, at 9:14 AM, Mark Phippard wrote: > > On Mon, Nov 29, 2021 at 10:10 AM Luke Mauldin wrote: >> >> Is there a recommended way to do a full text search of commits that include >> changed text. For example if I wanted “svn log” to show me all of that >> commits that have an added or deleted line that contains “foo”, is that >> possible? Git has similar functionality in “git log -S foo” >> Using “svn diff -r:HEAD | grep foo” gets me close but that just gives me the >> lines that changed and not the commit that they changed. > > With newer versions of SVN, the log command has a --search argument: > > https://svnbook.red-bean.com/nightly/en/svn.ref.svn.html#svn.ref.svn.sw.search > https://subversion.apache.org/docs/release-notes/1.8.html#svn-log-search > > Mark
Full text search
Is there a recommended way to do a full text search of commits that include changed text. For example if I wanted “svn log” to show me all of that commits that have an added or deleted line that contains “foo”, is that possible? Git has similar functionality in “git log -S foo” Using “svn diff -r:HEAD | grep foo” gets me close but that just gives me the lines that changed and not the commit that they changed.
Re: Svnadmin verify question
Does the Svnadmin verify do checksum checks? How does it verify validity? > On Nov 3, 2021, at 1:44 PM, Nathan Hartman wrote: > > On Tue, Nov 2, 2021 at 5:09 PM Luke Mauldin wrote: >> >> Can anyone tell me the details of the svnadmin verify command? Does >> subversion store any internal hash of each commit to verify its correctness >> and that it has not changed over time due to disk/memory errors or software >> bugs? >> >> Luke Mauldin > > Yes. The purpose of 'svnadmin verify' is to check for exactly those > kinds of errors. > > By default it runs through each revision one-by-one and stops/reports > if it finds a problem. There's also a --keep-going option since SVN > 1.9. > > It is a good idea to run 'svnadmin verify' periodically on > repositories to ensure their integrity. > > It is also crucial to have a good backup process in place, i.e., keep > multiple good up-to-date backups of repositories in different physical > locations and make sure you can restore from them before disaster > strikes. Obviously it's of no use to detect corruption if you don't > have backups to restore from. > > Hope this helps, > Nathan
Svnadmin verify question
Can anyone tell me the details of the svnadmin verify command? Does subversion store any internal hash of each commit to verify its correctness and that it has not changed over time due to disk/memory errors or software bugs? Luke Mauldin
Re: Current project status
You bring up a good point about the pre-commit code review process. I have never been in an organization that had strict pre-commit code review requirements so it wasn’t an issue. To me, so much of it just comes down to the developer. We have been doing interviews of Junior engineers and asking them the question “assume you have a Git repository, if you have local changes, and you need to get changes from master into your branch, what do you do?” The answer is surprisingly common to just make a local copy on the file system, reclone the git repo and then move the changes over manually….I cringe every time I hear that one. Regarding the merge tracking that wanted to be added, what end user functionality would that add? From my understanding through reading the docs and this earlier conversation, I thought that most of the merge tracking issues had been resolved? > On Oct 29, 2021, at 12:36 PM, Mark Phippard wrote: > > On Fri, Oct 29, 2021 at 1:26 PM Luke Mauldin wrote: >> >> Sorry to hear about the Teams / Sharepoint migration, that seems to be >> occurring industry wide. “Its moving to the cloud so it has to be better”. >> It also amazes me how much money and labor large companies are throwing at >> Git to have it scale to scenarios that it was never envisioned to support >> but every company has to be on Git because “thats what the developers want”. >> Every company that I have worked for that has used Git has always had a >> centralized Git repository just like SVN. From the SVN community’s >> perspective, I am curious to see their perspective on why the industry >> transitioned away from SVN to Git? > > > In my experience, it is the code review and branching workflows that > git enables that wins the day, With SVN the pre-commit review process > is too cumbersome and there is no real guarantee that what was > committed is what was reviewed. There have been several good solutions > for this built on Git, with the GitHub Pull Requests being the most > notable. > > In environments where pre-commit code review is not part of the > culture or process I find it hard to beat the SVN workflow for ease of > use. Conceptually, I have always liked the way SVN models a versioned > file system but it has also been the achilles heel when it comes to > using folders to model branches and tags so that neither of those > features truly exist in SVN and are really more conventions that one > can adopt in the folder structure. SVN's extreme flexibility has also > made it difficult to develop some of the features we wanted like merge > tracking because it became an endless slog of dealing with weird edge > cases. > > Mark
Re: Current project status
Sorry to hear about the Teams / Sharepoint migration, that seems to be occurring industry wide. “Its moving to the cloud so it has to be better”. It also amazes me how much money and labor large companies are throwing at Git to have it scale to scenarios that it was never envisioned to support but every company has to be on Git because “thats what the developers want”. Every company that I have worked for that has used Git has always had a centralized Git repository just like SVN. From the SVN community’s perspective, I am curious to see their perspective on why the industry transitioned away from SVN to Git? It is nice to look at the repository itself and see continued commits. Are most of these by community members or are some large companies still contributing back? Luke > On Oct 29, 2021, at 10:43 AM, Stuempfig, Thomas > wrote: > > Hi Luke, > the repository has been migrated with the Migration from Skype to Teams / > Sharepoint. (In my view, the worst case scenario) > we lost history of projects and we lost the search capabilities. But we were > forced… > > I was quite fine with the “slow” evolution of svn, and the flexibility > between client and server versions. So migrations were very smooth. > Even with kind of “simple SVN” versus fancy Document Management Tools or git, > our end users had exactly what they needed. A tool that reliably worked. > I would do the same today if I were asked. > > Looking into the subersion apache repository (source code) one can see that > There is continued commiting to the source code. I would not say that this is > a dead project, in contrary. > > From: Luke Mauldin > Sent: Donnerstag, 28. Oktober 2021 15:26 > To: Stuempfig, Thomas (DI SW GS&CS EU DACH AUTO PRBD EC) > > Cc: Justin MASSIOT | Zentek ; Nico Kadel-Garcia > ; Subversion > Subject: Re: Current project status > > Is the SVN repository still in use or was it transitioned to something else? > The primary users of this SVN repo will be engineers who are not software > developers so I think the less complex nature of SVN compared to Git could be > a definite advantage. However, I am concerned about the long-term viability > of the SVN project because I would like the repo to still be usable by in 5-8 > years. Just looking at the development mailing lists, it looks like almost > all development has stopped on Subversion which is concerning to me. > > Luke > > > On Oct 28, 2021, at 8:14 AM, Stuempfig, Thomas <mailto:thomas.stuemp...@siemens.com>> wrote: > > Hi all, > we had a SVN Repository that served a huge number of PPT Presentations, CAD > Data (MCAD/ECAD), Word. > the repository served over 10 Years of history of ~200 users. > In addition to this, we created useful Web Search Capabilities for PPTs in > the repository on our own based on office and svn api. > (We were able to search for single slides of presentations) > > We even thought of redmine integration in order to track Document Changes > against a Tasks… > > TortoiseSVN was easy enough for the average user and the checked out copy was > really great for us as we travelled a lot during the week. > Check-In and Updates from colleges were done when we had network access. > > The maintenance effort of this Project was really minimal and the effort for > errors / misuse was virtually inexistent. > > > Regards > Thomas > > From: Justin MASSIOT | Zentek <mailto:justin.mass...@zentek.fr>> > Sent: Donnerstag, 28. Oktober 2021 09:47 > To: Luke Mauldin mailto:lukemaul...@icloud.com>> > Cc: Nico Kadel-Garcia mailto:nka...@gmail.com>>; > Subversion mailto:users@subversion.apache.org>> > Subject: Re: Current project status > > 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. > > Justin MASSIOT | Zentek > > > On Thu, 28 Oct 2021 at 00:47, Luke Mauldin <mailto:lukemaul...@icloud.com>> wrote: > Let me clarify. The binaries can be unity 3d models or other engineering > assets
Re: Current project status
The other option for me at the moment is to use Git and LFS which is somewhat similar but not ideal. You mention renames as an example of a problem that are unlikely to ever be resolved. Can you please elaborate on the issue? My understanding is that especially the newer versions of SVN potentially do a better job of tracking renames than Git because SVN actually tracks more file level information whereas Git only tracks the contents of files. Many times I have renamed a file in Git and then also changed a couple of lines of text and Git sees it as a delete/add and not a rename. I know that there are various options you can set in Git to allow 90% of text similarity to be tracked as a rename but its just a pain and not intuitive at all. Luke > On Oct 28, 2021, at 8:43 AM, Mark Phippard wrote: > > On Thu, Oct 28, 2021 at 9:26 AM Luke Mauldin wrote: >> >> Is the SVN repository still in use or was it transitioned to something else? >> The primary users of this SVN repo will be engineers who are not software >> developers so I think the less complex nature of SVN compared to Git could >> be a definite advantage. However, I am concerned about the long-term >> viability of the SVN project because I would like the repo to still be >> usable by in 5-8 years. Just looking at the development mailing lists, it >> looks like almost all development has stopped on Subversion which is >> concerning to me. > > IMO, this should not be a big concern. Subversion development is slow > because the project is mature and stable. But for example, there was > some recent discussion and activity about making even more > improvements to handling of large binary files (your use case): > https://mail-archives.apache.org/mod_mbox/subversion-dev/202107.mbox/%3c874kcf6xin@red-bean.com%3e > I think this is an example of the type of improvement that will come > to this project in the coming years, but there are only so many of > these refinements left to make. I do not think any of the really big > problems, like how renames are handled, are likely ever to be solved. > > Ultimately what is the alternative? Not use version control at all? If > some better alternative emerges in the next 5-8 years it will almost > certainly provide a migration path for SVN repositories. You are > probably going to want to use a GUI client like TortoiseSVN. I have > not followed that recently but it is usually pretty active and there > is always room to make significant improvements in GUI clients that do > not require any changes in the core SVN API as most of them are just > about optimizing workflows. > > Mark
Re: Current project status
Is the SVN repository still in use or was it transitioned to something else? The primary users of this SVN repo will be engineers who are not software developers so I think the less complex nature of SVN compared to Git could be a definite advantage. However, I am concerned about the long-term viability of the SVN project because I would like the repo to still be usable by in 5-8 years. Just looking at the development mailing lists, it looks like almost all development has stopped on Subversion which is concerning to me. Luke > On Oct 28, 2021, at 8:14 AM, Stuempfig, Thomas > wrote: > > Hi all, > we had a SVN Repository that served a huge number of PPT Presentations, CAD > Data (MCAD/ECAD), Word. > the repository served over 10 Years of history of ~200 users. > In addition to this, we created useful Web Search Capabilities for PPTs in > the repository on our own based on office and svn api. > (We were able to search for single slides of presentations) > > We even thought of redmine integration in order to track Document Changes > against a Tasks… > > TortoiseSVN was easy enough for the average user and the checked out copy was > really great for us as we travelled a lot during the week. > Check-In and Updates from colleges were done when we had network access. > > The maintenance effort of this Project was really minimal and the effort for > errors / misuse was virtually inexistent. > > > Regards > Thomas > > From: Justin MASSIOT | Zentek > Sent: Donnerstag, 28. Oktober 2021 09:47 > To: Luke Mauldin > Cc: Nico Kadel-Garcia ; Subversion > > Subject: Re: Current project status > > 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. > > Justin MASSIOT | Zentek > > > On Thu, 28 Oct 2021 at 00:47, Luke Mauldin <mailto:lukemaul...@icloud.com>> wrote: > Let me clarify. The binaries can be unity 3d models or other engineering > assets. They are not compiled code. > > > On Oct 27, 2021, at 5:42 PM, Nico Kadel-Garcia > <mailto:nka...@gmail.com>> wrote: > > > > On Wed, Oct 27, 2021 at 6:31 PM Luke Mauldin > <mailto:lukemaul...@icloud.com>> wrote: > >> > >> We are considering using Subversion for a project with large binary files > >> since it seems to have some strengths in that area compared to the > >> alternatives. But now that the Apache Software Foundation and most other > >> projects such LLVM and FreeBSD have migrated away from Subversion, what > >> does the future of Subversion look like? Is it still being actively worked > >> on? Is anyone sponsoring it? > > > > For me, subversion still has uses by compelling centralized change > > tracking, and by permitting checkouts of very small directories from a > > master repo or a designated tag. > > > > Large binaries. just don't put those in source control. Put those > > in software packaging. > - > Siemens Industry Software GmbH; Anschrift: Am Kabellager 9, 51063 Köln; > Gesellschaft mit beschränkter Haftung; Geschäftsführer: Dr. Erich Bürgel, > Alexander Walter; Sitz der Gesellschaft: Köln; Registergericht: Amtsgericht > Köln, HRB 84564; Vorsitzender des Aufsichtsrats: Timo Nentwich >
Re: Current project status
Let me clarify. The binaries can be unity 3d models or other engineering assets. They are not compiled code. > On Oct 27, 2021, at 5:42 PM, Nico Kadel-Garcia wrote: > > On Wed, Oct 27, 2021 at 6:31 PM Luke Mauldin wrote: >> >> We are considering using Subversion for a project with large binary files >> since it seems to have some strengths in that area compared to the >> alternatives. But now that the Apache Software Foundation and most other >> projects such LLVM and FreeBSD have migrated away from Subversion, what does >> the future of Subversion look like? Is it still being actively worked on? Is >> anyone sponsoring it? > > For me, subversion still has uses by compelling centralized change > tracking, and by permitting checkouts of very small directories from a > master repo or a designated tag. > > Large binaries. just don't put those in source control. Put those > in software packaging.
Current project status
We are considering using Subversion for a project with large binary files since it seems to have some strengths in that area compared to the alternatives. But now that the Apache Software Foundation and most other projects such LLVM and FreeBSD have migrated away from Subversion, what does the future of Subversion look like? Is it still being actively worked on? Is anyone sponsoring it? Luke Mauldin
