RE: Current project status

[Stuempfig, Thomas]

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 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

Re: Current project status

[Luke Mauldin]

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  > 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 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  > 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 
> >> alternat

Re: Current project status

[Mark Phippard]

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

[Luke Mauldin]

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