vasupcre.blogg.se - Svn keyword

#Svn keyword how to
#Svn keyword Patch
#Svn keyword full

fine for $Rev: 10617 $, but $URL: file:///C:/Workspace/src/svn/mirrors/teo-trac-mirror/trunk/sample-plugins/Timestamp.py $)

the substitution works as expected (i.e.

I also noticed that with the patch, the svn:eol-style native files are exported in DOS format (on Windows) before it was exported as unix style (only the svn:eol-style CRLF ones were exported as DOS format).

the memory usage is sensibly the same (checked on Windows with psutil psutil.Process(os.getpid()).get_ext_memory_info()).

it takes 3s with the patch, 1.6s without.

So I did the testing myself on a svn mirror of the Trac repository, creating a.

#Svn keyword full

zip from the repository, as this will involve many such context creations and full content retrieval and processing. timings and memory usage measurement with big files?

#Svn keyword Patch

The patch also works for the 0.11 and 0.12 lines with a minor change to track the difference in the _to_svn() API. However it does have one slightly unexpected side effect: as the keywords are always substituted, diffs rendered by Trac (both in revision history views and changeset views) will show differences for the keywords, even though the underlying file within SVN does not technically have those changes (although the working copies would). This solution is attractive (at least to me) as the keywords are substituted for ALL consumers of the node (ZIP, Original Format, and general browsing). The patch also includes unit tests (added to source:/trunk/trac/versioncontrol/tests/svn_fs.py), and a slightly updated svnrepos.dump to provide a reference file with keywords to compare against. The attached patch against implements a lightweight wrapper around the SVN core.Stream class that overrides read() to find and replace the svn:keywords as they are read from the node.

(at least to me) there does not appear to be an extension point that can hook into the repository system between the actual repository and all renderers.

check for the svn:keywords property, parse the keywords, look up the information from the repository to correctly fill in the data, parse the file contents).

to properly process the keywords, the processor needs somewhat intimate access to the file node (e.g.

this issue is specific to SVN repositories: other repository formats have different keyword substitution schemes.

#Svn keyword how to

I spent a long time thinking about how to implement this as a plugin, and in the end, I feel it should be part of the core svn_fs for the following reasons: I have hit this issue as well (under an almost identical scenario to comment:10).