Re: ASF Subversion version
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: CVE-2021-44228 log4j vulnerability
On Mon, Dec 13, 2021 at 1:35 AM Bo Berglund wrote: > On Sun, 12 Dec 2021 15:30:20 +0300, Pavel Lyalyakin > wrote: > > >Apache Subversion and Apache HTTP Server are not Java applications. > >Subversion does not depend on log4j. AFAIK, Apache HTTP Server does not > >depend on log4j either. > > Sounds good. > > We are using VisualSVN on our main SVN server running on Windows Server > 2016: > > H:\>svnadmin --version > svnadmin, version 1.9.7 (r1800392) >compiled Nov 21 2017, 12:52:53 on x86_64-microsoft-windows6.1.7601 > > It has no exposure to the Internet, just sits on the LAN. > > > We have a backup server off-site running on Ubuntu Server 20.04.3: > > $ svnadmin --version > svnadmin, version 1.13.0 (r1867053) >compiled Mar 24 2020, 12:33:36 on x86_64-pc-linux-gnu > > The latter is svnsync'ed from VisualSVN every night and is fully updated. > It has no public interface, set to readonly except for the svnsync calls. > > Do we need to do anything for the "log4j" vulnerability? > > > -- > Bo Berglund > Developer in Sweden > > The vulnerability CVE-2021-44228 in the Java-based library Log4j affects Java-based products that depend on the Log4j library. As I said above, Apache Subversion is not a Java application and it does not use Log4j. VisualSVN Server is also not a Java application and it does not use Log4j. -- With best regards, Pavel Lyalyakin VisualSVN Team
Re: CVE-2021-44228 log4j vulnerability
On Mon, 13 Dec 2021 11:55:18 +0300, Pavel Lyalyakin wrote: >The vulnerability CVE-2021-44228 in the Java-based library Log4j affects >Java-based products that depend on the Log4j library. As I said above, >Apache Subversion is not a Java application and it does not use Log4j. >VisualSVN Server is also not a Java application and it does not use Log4j. Thanks you for verifying this to me! Much obliged. :) -- Bo Berglund Developer in Sweden
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
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.
Re: ASF Subversion version
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
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
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
Den mån 13 dec. 2021 kl 20:26 skrev Luke Mauldin : > 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. > ASF is depending on fundraising and it isn't overly rich. FY19 showed a net profit of 329 k$ while FY20 showed a net loss of 277 k$. There is enough money to run the foundation for a year, *maybe* two if funding dried up. That is not exactly a situation to employ paid developers. I'm also afraid that Subversion would not be the first project in the queue. But I would be glad to be proven wrong and see a big corporate sponsor showing up with donations earmarked just for Subversion. In the meantime we all should do what we can and, as Nathan already wrote, every bit counts. Our company use Subversion professionally, but as end users so I can't give my boss a business case to allocate much developer resources, however we are using a commercially licensed server (from one of the companies who from time to time show up in the mailing lists and in the "commits" archive). I'm stealing a few unused cycles to help on the mailing lists and I'm also using a few hours of my free time to look at the code to (hopefully) learn a few skills that will make me a better developer. Kind regards, Daniel
Re: Compression Question
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? As I understand it, the motivation for adding LZ4 compression (added in 1.10) was speed. From vague memory (I haven't looked into compression algorithms recently), I think zlib achieves a better compression ratio in terms of disk space saved, but LZ4 is faster. I haven't had experience with zstd yet. It is difficult to say which compression format would give the "best" performance for a particular application without some experimentation because things like hardware I/O speeds and the nature of the data being compressed affect the outcome. Are you looking for the best speed, the best compression ratio, a good tradeoff between the two? If you want to conserve disk space, I would suggest (if it's feasible and on a separate machine, not in production), to produce a dumpfile and load it twice, once with zlib and once with LZ4, and then compare the resulting on-disk sizes to that of the volumes on zstd. Note Subversion's data deduplication feature: if this was turned off in the past or is off now, some or all of your repo might contain duplicated data; to make the experiment "fair" you would need to take this into account. If you are looking for best performance in terms of speed, I don't have a simple answer for this because it depends on a great many variables in which Subversion's compression is but one. I would assume that networking I/O probably plays a bigger role than compression here. Hope this helps, Nathan
