Re: Current project status
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.
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.
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 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 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. >
RE: Current project status
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
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
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
TortoiseSVN is stable and mature, so its development status is slow :-) But I mostly agree with Mark, using SVN is better than nothing after all. And because it's mature, it's unlikely that you find a bug that is critical for your everyday use... Justin MASSIOT | Zentek On Thu, 28 Oct 2021 at 15:43, 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
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
On Thu, Oct 28, 2021 at 10:01 AM Luke Mauldin wrote: > > The other option for me at the moment is to use Git and LFS which is somewhat > similar but not ideal. It is a viable option but I would say the biggest problem is you still have to clone the entire repository which may or may not be ideal for your situation. With SVN, if you can come up with a folder structure that makes sense a user only has to checkout the partial subtree they care about. For someone working on CAD files exclusively this may be preferable. > 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. The roadmap page has links to the main tracking issues: https://subversion.apache.org/roadmap.html SVN's design handles renames well from a version control history point of view, but it does not handle them well when doing things like merge or even update if you have local mods to a file that was renamed. Git actually handles this much better. SVN has tried to solve it with the tree conflict feature and incremental progress has been made to resolve those tree conflicts better but it still leaves a lot to be desired. Of course all of this is only relevant for text files so I was not sure if this was even an issue for you. I was assuming your project was all binary files. If regular source code is the bulk of your needs then I would probably look at Git + LFS. Especially if you could isolate the binaries to multiple separate repositories so that a user was not forced to checkout unwanted files. Aside from the rename handling, I think Git is better because of the code review workflows it can provide better than SVN. Mark
Re: Current project status
On Thu, Oct 28, 2021 at 3:47 AM Justin MASSIOT | Zentek 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. 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. Also, you do have access to the full source code, so your data isn't being held in someone's undocumented silo. This was the biggest reason why at my $dayjob the first requirement any version control system had to meet before we would adopt it was to be open source. That's my 2 cents... Hope that helps! Nathan
Re: Current project status
On Thu, Oct 28, 2021 at 09:01:02AM -0500, Luke Mauldin wrote: > 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. I guess what Mark was referring to is a solution that would involve server-side changes. Many potential solutions were discussed over time, and some of them were even partially implemented but never went beyond experimental status. Several proposals included changes to the repository storage format as well as network procotol changes. Our current solution for resolving tree conflicts is client-side only, and as such it may not fit everyone's definition of "rename tracking". Essentially, the client runs the equivalent of 'svn log -v' and traces copyfrom information and deletions of relevant paths to figure out whether a rename might have occurred. In other words, it does exactly what a competent human would do to understand a rename conflict situation. The client has to fall back to human guidance in case of ambiguity, where multiple copies map to the same deleted path. In a perfect world the client should not have to fall back on human guidance because the user did already inform Subversion about the rename when they ran 'svn move'. However, a move operation is translated to copy+delete when a commit is made, so any move information the client had recorded is lost. On the upside, our current approach works against any server, which is important since it is generally easier to install up-to-date clients than upgrading existing server deployments. And the conflict resolution framework we have in the client has been designed with extensibility in mind. It is possible to add support for additional conflict cases by implementing a couple of funtions of C code. The current coverage is not complete, most importantly it doesn't handle cases where files have become directories or vice versa. But the only reason it does not handle such cases is lack of time and motivation to work on the missing bits. There is no technical reason it couldn't be done. What we have now seems to be good enough to cover what most people need. We do not hear complaints about this topic anymore so either people who used to complain have abandoned SVN or the solution we have is good enough. We cannot really tell the difference :)
Re: Current project status
On Thu, Oct 28, 2021 at 10:24:55AM -0400, Mark Phippard wrote: > SVN's design handles renames well from a version control history point > of view, but it does not handle them well when doing things like merge > or even update if you have local mods to a file that was renamed. Git > actually handles this much better. SVN has tried to solve it with the > tree conflict feature and incremental progress has been made to > resolve those tree conflicts better but it still leaves a lot to be > desired. What is left to be desired when updating or merging a renamed file with local mods? As far as I know, in current versions of SVN, this is working quite well. Like with Git's heuristics-based approach, some cases are handled much better than others. But simple file renames should be fine. I don't know what the various SVN GUI clients have implemented on top of the functionality we have built. But our command line client should not even require additional user input in most such cases and just do the "right thing" automatically.
Re: Current project status
On Thu, Oct 28, 2021 at 11:15 AM Stefan Sperling wrote: > > On Thu, Oct 28, 2021 at 10:24:55AM -0400, Mark Phippard wrote: > > SVN's design handles renames well from a version control history point > > of view, but it does not handle them well when doing things like merge > > or even update if you have local mods to a file that was renamed. Git > > actually handles this much better. SVN has tried to solve it with the > > tree conflict feature and incremental progress has been made to > > resolve those tree conflicts better but it still leaves a lot to be > > desired. > > What is left to be desired when updating or merging a renamed file > with local mods? As far as I know, in current versions of SVN, this > is working quite well. That is good to hear. I have tried to follow all of the progress you have made over the last few releases but I mainly use Git in day to day work now and have not gone to trouble of setting up examples to try it all out. Does it all happen automatically now? I thought at one point we still created the tree conflict and then you had to run svn resolve or something like that to trigger the resolution? Does any of the resolution just happen automatically in the libraries or for something like Subclipse would a bunch of new stuff need to be exposed to JavaHL and then we would have to fill in an implementation? Mark
Re: Current project status
On Thu, Oct 28, 2021 at 11:19:43AM -0400, Mark Phippard wrote: > On Thu, Oct 28, 2021 at 11:15 AM Stefan Sperling wrote: > > > > On Thu, Oct 28, 2021 at 10:24:55AM -0400, Mark Phippard wrote: > > > SVN's design handles renames well from a version control history point > > > of view, but it does not handle them well when doing things like merge > > > or even update if you have local mods to a file that was renamed. Git > > > actually handles this much better. SVN has tried to solve it with the > > > tree conflict feature and incremental progress has been made to > > > resolve those tree conflicts better but it still leaves a lot to be > > > desired. > > > > What is left to be desired when updating or merging a renamed file > > with local mods? As far as I know, in current versions of SVN, this > > is working quite well. > > That is good to hear. I have tried to follow all of the progress you > have made over the last few releases but I mainly use Git in day to > day work now and have not gone to trouble of setting up examples to > try it all out. > > Does it all happen automatically now? I thought at one point we still > created the tree conflict and then you had to run svn resolve or > something like that to trigger the resolution? The tree conflict conflict will still be created. The client will invoke the resolver automatically when this happens. If the resolver detects just one possible conflict resolution option then the client uses this option automatically. The client will prompt only when the resolver offers multiple options. In some cases we might prompt anyway even if just one option is found, but non-ambiguous moves should be followed without further interaction required by the user. The logic for presenting and picking resolution options is fully under the client's control. So some clients might show different behaviour if they have not been updated to make use of new APIs. Clients do not need to care in any way which options are available and how their resolution strategies are implemented. That is all handled by the library. Clients only need to take care of presentation, and perhaps make a decision on behalf of the user if there is only one option. > Does any of the resolution just happen automatically in the libraries > or for something like Subclipse would a bunch of new stuff need to be > exposed to JavaHL and then we would have to fill in an implementation? JavaHL might still be missing some bits, yes. I am not quite sure. Your best starting point would be to check which svn_client_conflict APIs the command line client using and see whether any of them still need to be mapped to Java.
Re: Current project status
Den tors 28 okt. 2021 kl 15:55 skrev Justin MASSIOT | Zentek < justin.mass...@zentek.fr>: > TortoiseSVN is stable and mature, so its development status is slow :-) > But I mostly agree with Mark, using SVN is better than nothing after all. > And because it's mature, it's unlikely that you find a bug that is critical > for your everyday use... > TortoiseSVN might be a bit slow, but it seems to get things done where they need to be done. For example, it recently got support for the new Win11 context menus, I'm running my own build and it seems to work very well. (The release pace seems to follow the Subversion release pace so the Subversion project really needs to do a new release asap). Kind regards Daniel (Full disclaimer: I'm a contributor both to Subversion and TortoiseSVN)
Re: Current project status
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 > 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
RE: Current project status
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. 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 - Siemens Industry Software Gm
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
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
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
Hi all, one thing that i really missed, was rename tracking. Other thing that I missed would be attributes for files, folders and commits. This would enable a better search. Search for all commits that touch business critical PRs... or files that touch about a system or requirement... I know, one should go for an ALM System for that. But somehow, I wished not to have to maintain an ALM System. But that's history, our situation is worse... Hope the best for you all, and I was really happy for the responsiveness in this forum. Regards Thomas -Original Message- From: Luke Mauldin Sent: Freitag, 29. Oktober 2021 19:46 To: Mark Phippard Cc: Stuempfig, Thomas (DI SW GS&CS EU DACH AUTO PRBD EC) ; Justin MASSIOT | Zentek ; Nico Kadel-Garcia ; Subversion Subject: 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 - 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
