arent branch first, and propagate them
into the `pristine-checksum-salt` branch from parent.
Thanks,
Evgeny Kotkov
ific edge-case might not be
worth introducing these regressions (which look significant, at least to me).
Thanks,
Evgeny Kotkov
t doesn't support SHA-1 under
any circumstances, and declaring all previously available working copy
formats unsupported.
Regards,
Evgeny Kotkov
Evgeny Kotkov writes:
> Merged in https://svn.apache.org/r1905955
>
> I'm going to respond on the topic of SHA1 a bit later.
For the history: thread [1] proposes the `pristine-checksum-salt` branch that
adds the infrastructure to support new pristine checksum kinds in the working
copy
rt of Review-Then-Commit.
(At the same time I won't even try to /convince/ you, sorry.)
[1] https://www.apache.org/foundation/voting.html
[2] https://lists.apache.org/thread/ow2x68g2k4lv2ycr81d14p8r8w2jj1xl
Regards,
Evgeny Kotkov
re in r66017.
Thanks,
Evgeny Kotkov
/svn.apache.org/r1909089, so hopefully this regression will be fixed
in the next APR 1.7.x patch release.
Thanks,
Evgeny Kotkov
ail. It is entirely
your decision whether or not to take any action regarding this matter.
Thanks,
Evgeny Kotkov
and allows it to happen naturally,
without requiring any additional instructions or knowledge.
If we change the default to "no", this part of the experience could be worse,
because for the end users it might look like the credentials aren't being
stored for unknown reasons / a bug in the software.
Thanks,
Evgeny Kotkov
Evgeny Kotkov writes:
> > Now, how hard would this be to actually implement?
>
> To have a more or less accurate estimate, I went ahead and prepared the
> first-cut implementation of an approach that makes the pristine checksum
> kind configurable in a working cop
client_dll.vcxproj]
> D:\a\subversion\subversion\Release\subversion\libsvn_client\libsvn_client-1.dll
> : fatal error LNK1120: 1 unresolved externals
> [D:\a\subversion\subversion\build\win32\vcnet-vcproj\libsvn_client_dll.vcxproj]
> ]]]
Thanks, should be fixed in r1908042.
Regards,
Evgeny Kotkov
Evgeny Kotkov writes:
> While working on the patch, I have stumbled across a couple of issues:
>
> A) `svn upgrade` without arguments fails for a working copy with latest format
>
> $ svn checkout --compatible-version=1.15 wc
> $ svn upgrade wc
> $ svn: E155021: Workin
rocess by such means as vetoing a code change is maybe a bit over the
top. (In the meantime, I certainly won't object if you're going to use this
waterfall-like process for the changes that you implement yourself.)
Regards,
Evgeny Kotkov
ew
[2] https://www.apache.org/foundation/glossary.html#ReviewThenCommit
Regards,
Evgeny Kotkov
itory and their files are
checked out together, the content will change, allowing for a malicious
action.
Regards,
Evgeny Kotkov
till thought it’s worth mentioning.)
Anyway, I'll stop working on the branch, because a veto has been casted.
Regards,
Evgeny Kotkov
ope for this branch.
I can complete the work on this branch and bring it to a production-ready
state, assuming there are no objections.
Thanks,
Evgeny Kotkov
Karl Fogel writes:
> Now, how hard would this be to actually implement?
I plan to take a more detailed look at that, but I'm currently on vacation
for the New Year holidays.
Thanks,
Evgeny Kotkov
tines are optional, we lose the
possibility to rehash all contents in place. So we might find ourselves
having to choose between two worse alternatives of either requiring a
network fetch during upgrade or entirely prohibiting an upgrade of
working copies with optional pristines.
Thoughts?
Thanks,
Evgeny Kotkov
Evgeny Kotkov writes:
> I think that the `pristines-on-demand-on-mwf` branch is now ready for a
> merge to trunk. I could do that, assuming there are no objections.
Merged in https://svn.apache.org/r1905955
I'm going to respond on the topic of SHA1 a bit later.
Thanks,
Evgeny Kotkov
Evgeny Kotkov writes:
> > IMHO, once the tests are ready, we could merge it and release
> > it to the world.
>
> Apart from the required test changes, there are some technical
> TODOs that remain from the initial patch and should be resolved.
> I'll try to handl
copyfrom.
So maybe we cannot really extend that to "any file might not have a pristine"
without it being an incompatible change.
Thanks,
Evgeny Kotkov
r1905682, I slightly rephrased that part so that it would say:
"This client uses a deprecated API that does not support working copies
without local pristines")
Thanks,
Evgeny Kotkov
chnical
TODOs that remain from the initial patch and should be resolved.
I'll try to handle them as well.
Thanks,
Evgeny Kotkov
Evgeny Kotkov writes:
> Perhaps we could transition into that state by committing the patch
> and maybe re-evaluate things from there. I could do that, assuming
> no objections, of course.
Committed the patch in https://svn.apache.org/r1905324
I'll try to handle the related tasks in
Karl Fogel writes:
> By the way, in that thread, Evgeny Kotkov -- whose initial work
> much of this is based on -- follows up with a patch that does a
> first-pass implementation of 'svn checkout --store-pristines=no'
> (by implementing a new persistent setting in wc.db).
Perh
as an example of the libsvn_wc API user,
other existing third-party users of the API could face the same problem.
Perhaps, we could bump the APIs that currently rely on the text-bases to
always be available. And we could then make their deprecated versions
fail (predictably) for working co
and
apr_file_sync() due to always doing just an fsync() instead of F_FULLFSYNC
when it's supported).
Thanks,
Evgeny Kotkov
ease
might be unexpected for its callers.
Thoughts?
(A small disclaimer: these changes have slipped past my attention until now,
when I tried updating to 1.14.2. But better late than sorry…)
Thanks,
Evgeny Kotkov
ommon work flows.
+1.
Regards,
Evgeny Kotkov
th a UI option to select between the two states during
checkout (all pristines / pristines-on-demand) that is persisted in the
working copy.
A small final note is that I could be missing some details or other cases,
but in the meantime I felt like sharing the thoughts I had while working on
the proof-of-concept.
Thanks,
Evgeny Kotkov
stines might be missing.)
- To change this option programmatically, one would have to update an existing
config file, which could be a non-trivial technical task, considering things
like persisting comments and whitespace trivia.
Thanks,
Evgeny Kotkov
(On vacation for a couple of weeks, so might not be able to respond promptly.)
stines-on-demand'?
> - in the wc.db somewhere?
Thinking out loud, this sounds like a property associated with a specific
wc_id in the database. I would say that this pretty much rules out options
of storing it outside the wc.db.
Thanks,
Evgeny Kotkov
e is
hydrated, we still have to stat(), because if the file is no longer modified,
then we need to dehydrate.
Thanks,
Evgeny Kotkov
ere is
a network request that can now happen at an unpredictable moment of time.
So any operation that may access the pristine contents has to be ready for
a network fetch. Compared to that, fetching the required pristines before
the operation does not impose that kind of requirement on the existing code.
Thanks,
Evgeny Kotkov
an that a lot of the important subsurface work (such
as preserving the old behavior for existing working copies, running the tests
for both configurations, etc.) is already in place, so that we wouldn't have
to think about it further on.
Thanks,
Evgeny Kotkov
ing the
method_precondition() hook.
With the patch, `err` is checked even if all hooks DECLINE the operation.
Not too sure if that's intended, because the variable could potentially
contain an arbitrary value or a leftover from some previous call.
Thanks,
Evgeny Kotkov
r of the Subversion clients,
for example in cases where the (ignored) error occurred due to a non-successful
authorization check. Other DAV clients may be susceptible to some kinds of
unexpected behavior as well.
[1] https://svn.apache.org/r1892513
Thanks,
Evgeny Kotkov
Evgeny Kotkov writes:
> The current state is that the commit is going to fetch the original
> text-base before sending the delta.
>
> It should be technically possible to implement a behavior where the commit
> sends a delta if the local text-base is present, and a ful
eoretically some of what is
> needed to support this sort of commit ought to already exist in our
> server code.
With a bit more thought, sending a fulltext even to existing servers
indeed shouldn't be an issue, as it can happen in the form of a delta
against the empty source.
Thanks,
Evgeny Kotkov
ritten to the disk. The text-base file corresponding to the
old version gets cleaned up if it is not referenced by any other remaining
modified files.
Thanks,
Evgeny Kotkov
porate a switch to a different
checksum type without known collisions instead of SHA-1.
3. Fix the minor issues written down as TODOs in the code.
Thanks,
Evgeny Kotkov
Evgeny Kotkov writes:
> My attempt to fix this is by making checkout stream data to both pristine
> and the (projected) working file, so that the actual install would then
> happen as just an atomic rename.
For the record, I made a few additional changes, including a significant
Daniel Shahaf writes:
> Thanks for checking. How about adding it somewhere, then?
Yes, that will probably be useful. Would you have an opportunity to do so?
Thanks,
Evgeny Kotkov
t; future work for now.
>
> Are this problem and its proposed solution documented in a jira ticket?
No, I don't think so.
(Apparently, SVN-3264 [1] describes the checkout case, but I haven't done
a thorough search to see if export is mentioned somewhere.)
[1] https://issues.apache.org/jira/browse/SVN-3264
Regards,
Evgeny Kotkov
Evgeny Kotkov writes:
> URL: http://svn.apache.org/viewvc?rev=1886490=rev
> Log:
> In the update editor, stream data to both pristine and working files.
...
> Several quick benchmarks:
>
> - Checking out subversion/trunk over https://
>
> Total time: 3.861 s →
estart.
See
https://lists.apache.org/thread.html/6db0186496a46c9823a752b377e369eb4361c8a42e62fc7e601453c6%401440460036%40%3Cdev.subversion.apache.org%3E
Thanks,
Evgeny Kotkov
ts/tortoisesvn/scm/svn/commits/28674
Among the changes in APR 1.7.0, this one could be responsible for the faulty
behavior, since it changes how apr_stat() works for reparse points:
https://svn.apache.org/r1855950
Regards,
Evgeny Kotkov
Evgeny Kotkov writes:
> Apparently, there is a bug in the implementation of --normalize-props
> that only makes it automatically fix line endings in the values of the
> revision properties, but not node properties (as per the code around
> load-fs-vtable.c: set_node_property(
tuations.
I will try to nominate both of these fixes to our stable branches, once I
have some time for that.
Thanks,
Evgeny Kotkov
has all its symbols marked
as static and is not exposed to anyone else.
Also, this compile option only changes the default value of the corresponding
runtime option (SQLITE_CONFIG_MEMSTATUS), meaning that it can still be
changed later with sqlite3_config().
Thanks,
Evgeny Kotkov
with amalgamation:
https://github.com/sqlite/sqlite/blob/cc3f3d1f055/src/parse.y
https://github.com/sqlite/sqlite/blob/cc3f3d1f055/tool/mkkeywordhash.c
https://github.com/sqlite/sqlite/blob/cc3f3d1f055/test/attach4.test#L82
https://github.com/sqlite/sqlite/commit/bc6b8d73592ad72e674b10152012170a01c31c62
Thanks,
Evgeny Kotkov
only resolve a subset of certificate validation failures.
> So ... -1, please revert
Will certainly do, unless this new data alters your opinion on the topic.
Thanks,
Evgeny Kotkov
r now I chose to move the declarations to libsvn_fs_fs/fs_fs.h, to avoid
having two parallel interfaces and to only export the version that works
through the FS loader.
Thanks,
Evgeny Kotkov
gh the FS loader.
Regards,
Evgeny Kotkov
Index: build.conf
===
--- build.conf (revision 1857216)
+++ build.conf (working copy)
@@ -442,7 +442,7 @@ description = Subversion FSFS Repository Manipulat
type = exe
path = subversion/svnfsf
on my TODO list.
Regards,
Evgeny Kotkov
d maybe slow down the
cases where we have to remove multiple directories, with the post-commit
transaction directory cleanup being an example of such case.
Thanks,
Evgeny Kotkov
Index: subversion/libsvn_subr/io.c
===
--- subversion/l
her test on the RA layer for this case
is unnecessary and would just increase the maintenance costs — since this
is an FS layer bug and given that we already have the (more or less) minimal
regression test in terms of the amount of the FS API calls.
Regards,
Evgeny Kotkov
s it easier to find where the error came from.
Makes sense, committed in https://svn.apache.org/r1847596
Thanks,
Evgeny Kotkov
they succeed.
Apparently, this behavior is caused by a problem in the specific optimization
within the FSFS open_path() routine.
I constructed an FS regression test and committed it and the fix in:
https://svn.apache.org/r1847572
(I'll try to nominate it for backport once I get some time.)
Thanks,
Evgeny Kotkov
nue the work on this patch in the nearby
future; posting this in case it might be useful.)
Thanks,
Evgeny Kotkov
Index: notes/wc-ng/pristine-store
===
--- notes/wc-ng/pristine-store (revision 1844566)
+++ notes/wc-ng/pristine-store (working c
Stefan Sperling <s...@apache.org> writes:
>> Should I file an issue or add a regression test for this problem?
>
> Yes please.
>
> Thanks!
Issue: https://issues.apache.org/jira/browse/SVN-4739
Regression test committed in https://svn.apache.org/r1830083
Thanks,
Evgeny Kotkov
, (q) Quit resolution: a
Summary of conflicts:
Tree conflicts: 1
> svn st
! C test\wc\file.txt
> local file delete, incoming file delete or move upon update
Summary of conflicts:
Tree conflicts: 1
Should I file an issue or add a regression test for this problem?
Thanks,
Evgeny Kotkov
old in svnadmin
that enables the block read feature in fsfs (currently set to 64 MB, as per
svnadmin.c:BLOCK_READ_CACHE_THRESHOLD).
Regards,
Evgeny Kotkov
uld be fixed by https://svn.apache.org/r1826747 and proposed
for backport to 1.10.x.
Thanks,
Evgeny Kotkov
tions, I'll merge
the most recent relnotes follow-ups to 'publish' somewhere later today or
tomorrow.
Thanks,
Evgeny Kotkov
Julian Foad <julianf...@apache.org> writes:
> +1.
>
> (Nit: English idiom is "[is still] subject to".)
I incorporated this tweak and staged the changes in r1825865.
Thanks,
Evgeny Kotkov
I wouldn't say that it is productive to discuss issues
in such way. In my opinion, we should be doing it the other way around by
actually encouraging reports of various problems during the soak period.
Regards,
Evgeny Kotkov
might be worth considering before the
1.10 GA release.
Thanks,
Evgeny Kotkov
)
libsvn_ra_serf/util.c:svn_ra_serf__setup_svndiff_accept_encoding()
libsvn_ra_serf/commit.c:negotiate_put_encoding()
Thanks,
Evgeny Kotkov
esult in preferring LZ4
compression over low latency networks and zlib compression otherwise.
Below is the table explaining the used compression algorithm in each
combination of the client- and server-side configuration options:
[table]
]]]
Thanks,
Evgen
Evgeny Kotkov <evgeny.kot...@visualsvn.com> writes:
>> Index: subversion/mod_dav_svn/version.c
>> ===
>> --- subversion/mod_dav_svn/version.c(revision 1820704)
>> +++ subversion/mod_dav_
nding svndiff1 to servers that don't
advertise it with this specific header, as there might be third-party
implementations of the Subversion's HTTP protocol that can only
parse svndiff0).
Thanks,
Evgeny Kotkov
versions?
I think that we might be able to selectively stop advertising the new-
in-1.10 capabilities based on the SVNMasterVersion value, similarly to
how we handle SVN_DAV_NS_DAV_SVN_EPHEMERAL_TXNPROPS.
Perhaps, we could do something along the lines of the attached patch?
Thanks,
Evgeny Kot
dumps of older repositories, but are rejected by Subversion 1.6
and later.
But, presumably, both variants are fine, as both of them explain the reason
behind the "Cannot accept non-LF line endings" error — so please feel free
to commit this tweak if you think it would be more appropriate.
Thanks,
Evgeny Kotkov
t; a small release notes entry for it?
Thanks for the reminder, committed in r1818496:
https://svn.apache.org/r1818496
https://subversion-staging.apache.org/docs/release-notes/1.10.html#normalize-props
Regards,
Evgeny Kotkov
Note that the
complete text of every "word" is stored twice: once in the main
table and again in the index.
Although I didn't check if the most recent SQLite version still behaves in
the described way internally, I have witnessed the described close-to-2x
reduction in the size of rep-cache.db — which, unless I am missing
something, follows the described idea of this optimization.
Thanks,
Evgeny Kotkov
my guess would be that a substring search would work well in the majority
of scenarios.
(Also, as far as I recall, `log --search` currently searches for a substring,
so that would be consistent with it, and would probably avoid surprising
the users by having a switch with the same name, but behaving differently.)
Thanks,
Evgeny Kotkov
hz and HTTPS. Apparently, this behavior is specific
to 1.10, as I cannot reproduce it with 1.9 binaries.
(I haven't investigated the issue any further at this time, and it might as
well be reproducible in other configurations.)
Thanks,
Evgeny Kotkov
Evgeny Kotkov <evgeny.kot...@visualsvn.com> writes:
> I think that it would be nice to have this optimization in rep-cache.db,
> and that we can start using it in a compatible way:
>
> - All existing rep-cache.db statements are compatible with it.
>
> - Since SQLite
that
all binaries supporting format 8 can work with the tables with this
optimization.
Would there be any objections to a change like this (see the attached patch)?
[1] https://sqlite.org/withoutrowid.html
Thanks,
Evgeny Kotkov
fsfs: Use the `WITHOUT ROWID` optimization for rep-cache.db
f.
I concur that the time-based releases most likely won't happen just based
on the agreement, and that there has to be a person driving them.
Perhaps, we could try this approach by finding a volunteer responsible for
RM-ing the 1.11 release — for example, right after 1.10 is released.
Regards,
Evgeny Kotkov
d v7.
(Also, I think that the main.py:parse_options() function may need an update
to properly handle the added v1-v3 precooked repositories by downgrading
the server_minor_version — as otherwise, the various test suite checks such
as server_has_mergeinfo() won't kick in.)
Thanks,
Evgeny Kotkov
ntly, I don't
> monitor the commit activity closely.
I committed the implementations of (1) and (2) in
https://svn.apache.org/r1816347 and
https://svn.apache.org/r1816348
respectively.
Thanks,
Evgeny Kotkov
with an
uniquifier.
Barring objections and alternative suggestions, I could give a shot at
implementing this.
Regards,
Evgeny Kotkov
info->size));
I think that using APR_SIZE_T_FMT would still lead to the same issue with
large file sizes in the 32-bit environment (where size_t is also 32 bit).
Perhaps, the code should be using APR_OFF_T_FMT as the format specifier?
(The apr_file_info_t.size value is an apr_off_t)
Regards,
Evgeny Kotkov
Evgeny Kotkov <evgeny.kot...@visualsvn.com> writes:
> Daniel Shahaf <d...@daniel.shahaf.name> writes:
>
>>> + *
>>> + * Any temporary allocations may be performed in @a scratch_pool.
>>
>> Need to add an @since tag here.
>
> [...]
>
Evgeny Kotkov <evgeny.kot...@visualsvn.com> writes:
> (2) I am going to tweak the new test so that it would properly open the
> parent directory and commit to a locked file, to have this case
> covered with a native test.
Committed in r1816060.
Julian Foad <julianf...@
R_WC_PATH_NOT_FOUND
svn: warning: W155010: The node 'C:\Project\unversioned' was not found.
..\..\..\subversion\svn\list-cmd.c:453: (apr_err=SVN_ERR_ILLEGAL_TARGET)
svn: E29: Could not list all targets because some targets don't exist
svn ls http://spbvo-ws09.ostyserver.net:8080/svn/master2 --search *
svn: E155007: 'C:\AnotherProject' is not a working copy
Thanks,
Evgeny Kotkov
ng, there should be no reason to explicitly
filter empty relpaths for the lock tokens since they are invalid.
(2) I am going to tweak the new test so that it would properly open the
parent directory and commit to a locked file, to have this case
covered with a native test.
Thanks,
Evgeny Kotkov
of the community. If you are interested in becoming a sponsor of
this event and supporting the further development of the project by such
means, please contact us at priv...@subversion.apache.org for details.
Thanks,
Evgeny Kotkov (VP Apache Subversion)
tion for
svnadmin load in https://svn.apache.org/r1807836
This option currently translates non-LF line endings found in the svn:
property values. I think that this should improve the situation for
users who attempt to load dump files with such property values.
Regards,
Evgeny Kotkov
at unused slots are filled in with no-op functions.
+ * use svn_delta_default_editor() or some other constructor, to avoid
+ * backwards compatibility problems if the structure is extended in
+ * future releases and to ensure that unused slots are filled in with
+ * no-op functions.
*
* Function Usage
*
]]]
Regards,
Evgeny Kotkov
ssarily restate
the information that's already available.
Also, I am not against the idea of tweaking the note by saying something
like "...because we may add new fields in the future", but I don't think
that it is required either. (In other words, I am +0 to that.)
Regards,
Evgeny Kotkov
s meaning "You may
> use malloc(..., sizeof(svn_delta_editor_t)) if you take care to initialize
> all struct members", in which case, his code will not be ABI compatible
> with 1.10.
I think that adding this callback does not affect the ABI compatibility.
The note says "Don't try to allocate one of these yourself", whereas the
malloc(..., sizeof(svn_delta_editor_t)) example does exactly the opposite.
Thanks,
Evgeny Kotkov
ve any real numbers at this time.
With that in mind, I have put nominating this change on my todo list,
unless someone else beats me to it.
Regards,
Evgeny Kotkov
a slightly better way would be to keep the case-insensitive behavior
by default, but add a "--case-sensitive" switch to handle the cases where
it's required?
That is,
svn ls --search
svn ls --search --case-sensitive
Regards,
Evgeny Kotkov
Evgeny Kotkov <evgeny.kot...@visualsvn.com> writes:
> In the meanwhile, apparently, there is an oversight in the core V1 patch
> (3-reduce-syscalls-for-buffered-writes-v1.patch.txt):
>
> If the buffer is not empty, and the caller issues a write with a chunk
> that slightly ex
Stefan Sperling <s...@apache.org> writes:
> \o/
>
> Can you please update the 1.10 release notes accordingly?
Will do, thanks for the reminder.
Regards,
Evgeny Kotkov
d the core change that makes LZ4 the new default for
format 8 repositories in https://svn.apache.org/r1805897
Regards,
Evgeny Kotkov
1 - 100 of 368 matches
Mail list logo
