Does SVNKit support Repository Dictated Config?

SVNKit
#1

Hi,

I’m wondering whether SVNKit supports Repository Dictated Config Apache Subversion 1.8 Release Notes ?

If so, does JetBrains need to enable/implement/upgrade anything in order for it to work?
Context: https://youtrack.jetbrains.com/issue/TW-75970/Versioned-settings-disregards-svn-auto-props-on-commit

Thanks!

Joachim

#2

Hello Joachim,

both svn:auto-props and svn:global-ignores are supported by SVNKit. You don’t need to do anything special to enable them. You can find the full list of supported properties in SVNProperty class.

But there’s a common misconception about how ‘auto-props’ work (both property-based or global config-based). The ‘auto-props’ are only applied when a new (not yet version-tracked) file is added with ‘svn add’ command or its SVN/SVNKit API analogue. If the file is already under version control, the ‘auto-props’ do not apply to such file.

I don’t fully understand the user’s scenario, but I guess ‘svn add’ is not a part of the building script on Teamcity and thus ‘auto-props’ should not be applied to it. So probably it’s an SVN client to blame for creating a revision without ‘auto-props’ applied. The client could still be SVNKit-based but anyway this would be beyond Teamcity’s responsibility.

Anyway if you or the user would manage to reproduce the problem on the minimal test repository, I would include the fix into SVNKit. It would be perfect if you or the user could write such a minimal test like this one. Then it would be much simpler to fix. By the way it already contains simple tests showing how ‘auto-prop’ are supposed to work.

But so far I think the problem is not caused by a bug but by wrong expectations.

#3

Hello Dmitry,

TeamCity adds files via API, with a call like

editor.addFile(myPath, null, -1);
// where editor comes from
editor = svnRepository.getCommitEditor(logMessage, null /*locks*/, true /*keepLocks*/, null /*mediator*/);

Are there any specific options or conditions which are required for auto-props to work?
How it should be enabled, if we work directly with SVNRepository class?

Thanks,
KIR

#4

Well, TeamCity is a closed-source product and I’m the user, so I don’t really know what’s going on behind the scenes, but here’s what I imagine:

The feature I’m trying to set up is “versioned settings”.
This means TC will create a set of files (xml, kotlin, …) that contain the settings of the builds that you define in the TC UI. This set of files is then committed to svn.

I’ve tried to find this set of files on disk on our TC server, but I’m unable to find them.

I don’t know whether these are “new” files that are created and added specifically for “versioned settings” or whether these are existing files.

In any case: without “versioned settings” these files are not in svn, so with “versioned settings” they must be 'svn add’ed one way or another…

In any case: thanks for the input, I’m sure this will help JetBrains to figure aout what’s wrong.

#5

Hello Kirill!

The

editor.addFile(...)

call is a part of ‘svn commit’ analogue which is another stage and at that moment auto-props are not applied. They are only applied when SVN/SVNKit interacts with a working copy. For command line SVN it’s ‘svn add’ command. For SVNKit it’s SvnScheduleForAddition class.

When using SVNRepository class, the auto-props are not applied automatically beause SVNRepository API doesn’t contain methods interacting with a working copy (it’s doesn’t even imply any working copy exists at all). Hence there’s no way to “enable” auto-props for SVNRepository class.

The SvnScheduleForAddition class (created by SvnOperationFactory) should handle the auto-props properly without further specific options or conditions.

If Teamcity re-implements “add and commit” functionality using low-level SVNRepository class, instead of high-level SvnOperationFactory and working copy, it should apply auto-props manually. Then I’ll tell you how to do that.

Look at SvnNgAdd#addFile (SvnNgAdd is a runner for SvnScheduleForAddition operation). This method is an analogue of ‘svn add’. It calls getAllAutoProperties() method which calls

  • SVNPropertiesManager.computeAutoProperties(...) to compute auto-props from the config; and
  • SvnNgPropertiesManager.parseAutoProperties(...) to compute auto-props from the svn:auto-props property.

Then it calls SvnNgPropertiesManager.getMatchedAutoProperties(...) to match the auto-props with the path of the newly added file. Teamcity should do the same if you want to continue using SVNRepository-level API and avoid using SvnOperationFactory API and real working copies.

1 Like
#6

@JoachimBeckers thanks for the details!

If TC indeed creates new revisions it’s its responsibility to apply auto-props. From Kirill’s post I’ve realized that TC uses low-level API (SVNRepository-based) which avoids creating a working copy. This is ok, but then it doesn’t automatically enjoy SVNKit’s features which are implemented in working copy-based API (SvnOperationFactory) so TC should either

  • switch to SvnOperationFactory API; or
  • implement auto-props manually.

Above I’ve instructed Kirill how to do that and I guess he will choose the second approach. Anyway, I was wrong: the problem seems to be not on your side, according to your description.

#7

Hello @dmitry.pavlenko,

Thanks a lot for the details on how to implement auto-props using the low-level API. We’ll see if it can be added to TeamCity automagically :)

Best,