On 08 Jan 2024, Daniel Shahaf wrote:
How is an interested community member supposed to get this list's
archives in mbox format?
Those on svn.haxx.se can be obtained from there, but what about
the
others? gmane is down, lists.a.o has a download feature that
seems to
require either downloadin
On 04 Jan 2024, Daniel Shahaf wrote:
Acknowledging receipt. I'll reply substantively when I have the
time to swap in the context.
Thanks. Yeah, I went through the same context-swapping-in process
yesterday before posting!
Best regards,
-Karl
Evgeny's work is on this branch...
https://sv
On 01 Apr 2023, Evgeny Kotkov via dev wrote:
Daniel Shahaf writes:
What's the question or action item to/for me? Thanks.
I'm afraid I don't fully understand your question. As you
probably remember, the change is blocked by your veto. To my
knowledge, this veto hasn't been revoked as of no
On 02 Mar 2023, Daniel Sahlberg wrote:
Hi,
During the Infra Roundtable yesterday a new self-serve for
creating
Jira accounts was announced. While I agree with Karl's 20+ year
old
e-mail about issue creations [1], the self-serve will inevitable
be
found and accounts will be created even if we
On 31 Jan 2023, Daniel Shahaf wrote:
Karl Fogel wrote on Mon, 30 Jan 2023 23:26 +00:00:
Daniel, given what's in Evgeny's branch now, could you
summarize
your current technical objections if any?
Certainly, but I won't have time to do so today.
Oh, my gosh, I'd be the
On 29 Jan 2023, VirusCamp wrote:
Hi, everyone.
I found a bug
in subversion-1.14.2\subversion\tests\cmdline\svntest\
main.py.
The bug makes `python win-tests.py --enable-sasl` failed for all
py
tests.
Thank you for the bug report. This is fixed now in r1907124.
The comma got introduced in
On 29 Jan 2023, Evgeny Kotkov via dev wrote:
I have *absolutely* no idea where "being railroaded through"
comes from.
Really, it's a wrong way of portraying and thinking about the
events that have
happened so far.
Reiterating over those events: I wrote an email containing my
thoughts
and expl
copies available in an official release as
soon as we can.
Best regards,
-Karl
On 21 Jan 2023, Daniel Shahaf wrote:
Karl Fogel wrote on Fri, Jan 20, 2023 at 11:09:11 -0600:
On 20 Jan 2023, Daniel Shahaf wrote:
> Evgeny Kotkov via dev wrote on Thu, 19 Jan 2023 18:52 +00:00:
> > I
On 20 Jan 2023, Nathan Hartman wrote:
Taking a step back, this discussion started because pristine-free
WCs
are IIUC more dependent on comparing hashes than pristineful WCs,
and
therefore a hash collision could have more impact in a
pristine-free
WC. "Guarantees" were mentioned, but I think it'
On 20 Jan 2023, Daniel Shahaf wrote:
Evgeny Kotkov via dev wrote on Thu, 19 Jan 2023 18:52 +00:00:
I can complete the work on this branch and bring it to a
production-ready
state, assuming there are no objections.
Your assumption is counterfactual:
https://mail-archives.apache.org/mod_mbox/s
On 19 Jan 2023, Evgeny Kotkov wrote:
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 copy.
The current implementation passes all tests in my environment and
seems to
On 19 Jan 2023, Daniel Shahaf wrote:
https://subversion.apache.org/security/sha1-advisory.txt
That's a well-written advisory. I was surprised to see that there
is no date on it, though -- from looking at the page, one would
have no quick way of knowing the date it was published (although
on
On 29 Dec 2022, Evgeny Kotkov wrote:
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.
That's great to hear, Evgeny. In the meantime, enjoy your
vacati
On 28 Dec 2022, Branko Čibej wrote:
My point was that we shouldn't have to worry about format bumps
as
much any more because we have infrastructure in the client for
supporting multiple WC formats. That includes optional pristines,
different hashes, compressed pristines, etc. etc.
Thank you fo
On 20 Dec 2022, Evgeny Kotkov via dev wrote:
[Moving discussion to a new thread]
We currently have a problem that a working copy relies on the
checksum type
with known collisions (SHA1). A solution to that problem is to
switch to a
different checksum type without known collisions in one of th
On 13 Dec 2022, Evgeny Kotkov wrote:
Evgeny Kotkov writes:
Merged in https://svn.apache.org/r1905955
W00t!! Thank you, and Julian and Daniel and everyone who's
contributed to this.
So... do we have a release manager? :-)
On 07 Dec 2022, Evgeny Kotkov wrote:
The branch passes all tests in my Windows and Linux environments,
in both
--store-pristine=yes and =no modes.
FYI, it passes all tests here too (on Debian GNU/Linux, up-to-date
'testing' distro). Attached file has details; there were some
XFAILs, but no
On 07 Dec 2022, Evgeny Kotkov wrote:
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.
+1, and thank you.
Now, I haven't had time to do a real code review -- my manager hat
get
On 29 Nov 2022, Johan Corveleyn wrote:
My thanks also to the courageous people having developed this,
and the
gentle souls keeping the ball rolling :-).
About the name:
[...]
FWIW, my vote still goes to --store-pristines={yes|no}
Same here, FWIW.
I understand the argument that this expos
On 16 Nov 2022, Evgeny Kotkov wrote:
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 handle them as well.
Thank you!
On 15 Nov 2022, Evgeny Kotkov wrote:
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 h
pports
it. However, if that's a complex change in the WC code, then
let's just release with whole-WC support and not delay.
Have I summarized the current status accurately? Thoughts?
Please see also Julian's status email from April, which goes into
more detail about which tests ne
On 06 Apr 2022, Julian Foad wrote:
Evgeny Kotkov wrote:
- revert the patch I applied, as it's papering over the
problem in an
incomplete way and so possibly causes more confusion than it
fixes.
- leave this issue open and come back to it later; it's an
edge case not
part of common work flow
On 30 Mar 2022, Julian Foad wrote:
Karl Fogel wrote:
I think printing these messages to stderr makes the most sense.
There are plenty of programs out there that parse the stdout of
'svn'; we don't want to interfere with them.
As you point out, it's especially importan
On 24 Mar 2022, Julian Foad wrote:
For 'svn diff' especially, if we don't print the notifications,
then we
miss out on informing the user during one of the times when it
could be
particularly valuable to them. (They are waiting for diff output,
which
previously in svn used to come quickly.)
I
On 22 Mar 2022, Mark Phippard wrote:
[... many lines omitted...]
For some reason, I need this with configure: --with-serf=/usr
With that, the davautocheck is running. Thanks for the tip on
that one.
I've been watching this thread with amazement and gratitude.
Thanks to everyone who's been h
On 18 Mar 2022, Nathan Hartman wrote:
tl;dr: Pretty darn good for a first cut!
W00t!
The versioned contents are source files; not exactly a huge WC by
today's standards but believe it or not this makes a big
difference
for me, as I often operate on WCs this size directly on embedded
systems
Hi -- I've just absorbed all of this thread that was new since the
last time I read it (that's a lot! :-) ).
I agree with Julian's judgement that we should just ship the MVP
version of our issue #525 solution with 'svn update' fetching
pristines for locally-modified files.
While it's not ide
On 10 Mar 2022, Lorenz wrote:
Daniel Sahlberg wrote:
Den tis 8 mars 2022 kl 14:17 skrev Daniel Shahaf
:
An alternative is to require the user to let svn know before
they're
starting to edit a file, so we can create a pristine off the
on-disk
file. This way we won't have pristineless modifi
On 09 Mar 2022, Julian Foad wrote:
Daniel Sahlberg wrote:
[...] an "iff". I guess this might be the "if and only if"
meaning [...]
Yes it is. OK, can change.
[...] mismatched quotes.
Thanks. Both fixed now in my local copy.
More substantive reviews are welcome too :-)
Might it be better
On 08 Mar 2022, Daniel Shahaf wrote:
Sure. I was asking whether by "once the user has a local
pristine" you
meant a pristine — as in, a file under .svn/pristine/ that
.svn/wc.db
knows about and uses — or Alice making a local copy of the
contents of
file@BASE somewhere libsvn doesn't know abou
On 08 Mar 2022, Daniel Shahaf wrote:
Hmm, I don't see where I was assuming that the pristine would
be needed
exactly once, though. Once the user has a local pristine (by
whatever
means),
To be clear, we're only talking about pristines that libsvn_wc
knows
about, right? As opposed to Alice
On 08 Mar 2022, Daniel Shahaf wrote:
I wasn't proposing we require such a step. I was merely saying
that was
one of several possible solutions to the "How to commit a
pristineless
file" question. Here they are again:
1. Download the pristine and then send a regular delta
2. Send a self-delta
On 08 Mar 2022, Daniel Shahaf wrote:
Karl Fogel wrote on Mon, Mar 07, 2022 at 13:44:03 -0600:
And in the absence of fancy cross-network common-prefix
detection code that
we're not going to write, this would just be cost-shifting
anyway. Whatever
commit-time improvement one would gain
On 08 Mar 2022, Daniel Shahaf wrote:
Karl Fogel wrote on Sun, Mar 06, 2022 at 22:19:50 -0600:
b) The failure mode of unnecessary fetching and storing is much
worse than
the failure mode of not having fetched a pristine that someone
might turn
out to want (there are workarounds for the latter
On 07 Mar 2022, Mark Phippard wrote:
I do understand the reasons why Evgeny thought pre-fetching
pristines for modified files as part of an 'update' could be a
good idea.
My recollection of the first version of this patch, commit needed
the
pristine and so had to fetch it before the commit hap
On 04 Mar 2022, Julian Foad wrote:
I had a talk with Karl about this, and now I understand the
concern much better.
(Karl, please correct anything I misrepresent.)
You've described it well, Julian. Thank you (and thank you also
for your patience in explaining to me the current State Of The
On 27 Feb 2022, Chih-Hsuan Yen wrote:
Oops, the mail subject should be "Pass $PINENTRY_USER_DATA to
pinentry
used in gpg-agent password store" (same as the svn commit
log). Sorry
for confusion.
No confusion at all, though thanks for following up. Your patch
from Feb. 22nd is on my review li
On 18 Feb 2022, Julian Foad wrote:
To understand, we need to recap that this design is based around
a
simple invariant: whenever a file is seen to be locally modified,
at the
next convenient opportunity we will download its base; and when
seen to
be not-modified we will discard its base. It is
On 15 Feb 2022, Nathan Hartman wrote:
Possibly bikeshedding a bit, but this seems to return to the idea
of
"turning on" what we are (tentatively) calling "local
base"... IMHO it
would be better if it were reversed to "--remote-base=yes" to
convey
that this is non-default and opt-in. (Or possib
On 15 Feb 2022, Mark Phippard wrote:
On Tue, Feb 15, 2022 at 12:00 PM Julian Foad
wrote:
Currently: "svn checkout --compatible-version=1.15". No feature
name
involved. Not saying that's good, just that's the current
state.
Are you saying this is how you would activate this no-pristines
featu
On 15 Feb 2022, Nathan Hartman wrote:
How about:
Remote BASE
(as opposed to Local BASE).
The idea here being that BASE is a concept with which users
should be
familiar, while pristines are part of Subversion's implementation
under the hood.
Getting closer, I think! "base" seems like a goo
On 14 Feb 2022, Julian Foad wrote:
Karl, thanks for bringing a user-focused perspective to the
naming. In
Subversion's UI we will not necessarily expose any name for the
feature,
but we might, e.g. in a configuration file or in help text. In
describing what's new in 1.15 people will certainly s
On 12 Feb 2022, Mark Phippard wrote:
Just to offer a counterpoint Karl, I always assumed the goal of
the
branch was to have no pristines in the WC and the "on-demand"
aspect
was referring to an internal SVN detail that it would have to
fetch
pristines when they were needed to complete a comman
On 11 Feb 2022, Julian Foad wrote:
Re. pristines-on-demand. I have re-based pristines-on-demand on
top of
multi-wc-format, resulting in a new branch
'pristines-on-demand-on-mwf'.
Julian, just FYI I committed r1898020 to update the
'BRANCH-README' file on the new 'pristines-on-demand-on-mwf'
I wrote:
...does the "pristines-on-demand" branch name still accurately
reflect
what the state of the onion will be after that branch is merged?
Ah, I'll retroactively update my question to now be about the new
"pristines-on-demand-on-mwf" branch, of course.
Best regards,
-Karl
On 10 Feb 2022, Julian Foad wrote:
My current plan:
* multi-wc-format is, I consider, ready for merge to trunk. See
thread [1].
-> Please review it.
- I can post a diff and a summary log message to help
reviewers.
* Make pristines-on-demand behaviour conditional on WC format.
-
On 10 Feb 2022, Stefan Sperling wrote:
On Thu, Feb 10, 2022 at 12:10:08AM -0600, Karl Fogel wrote:
I'm curious: what is the case that causes the patched target
file to have
different permissions than it had before the patch? (Or am I
misunderstanding what you're saying?)
Possibly
On 10 Feb 2022, Julian Foad wrote:
Julian Foad wrote:
pristines-on-demand behaviour needs to be made conditional on
WC format.
[...]
Once that is done, I plan to return to this per-WC config
option storage.
Now that we have (just) decided the default WC format will be the
old
format (31) an
On 09 Feb 2022, Ruediger Pluem wrote:
When rebuilding my own Subversion build I stumbled across the
following
patch that I add to my build:
Index: subversion/libsvn_client/patch.c
===
--- subversion/libsvn_client/patch.c(revisi
On 31 Jan 2022, Daniel Shahaf wrote:
The main use-case for pristineless files is large, undiffable,
undeltifiable files checked out from a box in the next rack unit
over
(= wide/cheap uplink and downlink).
Undiffable files will likely have svn:needs-lock on them, won't
they?
FWIW, I don't k
In an ideal world, I'd have time to study the details closely
enough that I would already know the answer to the question I'm
about to ask.
However, after (quickly) reading the posts so far, I still wasn't
completely clear on the answer, so... what the heck, I'll just
ask!
Does the current
On 27 Jan 2022, Daniel Shahaf wrote:
Hang on. Why do you assume that if someone has big files, then
they're
necessarily all out in a one directory and all the accompanying
texty
(or otherwise diffable) files are all in another directory?
Sure,
that's exactly kfogel's use-case (described upthre
On 25 Jan 2022, Daniel Shahaf wrote:
Karl Fogel wrote on Mon, Jan 24, 2022 at 12:35:10 -0600:
I'm partly just thinking out loud here, to stimulate us all to
think. None
of this affects the initial, whole-WC implementation, and of
course let's
keep in mind that the *main* use ca
On 24 Jan 2022, Daniel Shahaf wrote:
Sure! And a script for running «hydrate» automatically could be
called
"submerge". :)
And I guess we'll want `svn info` to grow a "Last watered at:"
line.
As long as we alias 'svn mop' for 'svn cleanup', it's fine with me
:-).
Agreed, but perhaps have
On 24 Jan 2022, Daniel Shahaf wrote:
[...] To be clear, I'm not trying to pick nits; I'm trying to
make sure that we don't make unwarranted assumptions. We might
get a lightbulb moment from that. (E.g., that's basically how we
realized we should deprecate --reintegrate, IIRC.)
Agreed. I
On 21 Jan 2022, Mark Phippard wrote:
One aspect of the previous thread that came up is that someone
demonstrated a simple script to create a cached password (as a
workaround for current users). That is what led to the idea of
formalizing this using the svn auth command to create this file.
I am
On 21 Jan 2022, Mark Phippard wrote:
In terms of what needs to be done, maybe I am wrong, but I did
not
think we had any mechanism in place where someone could choose
not to
compile in support for this feature. So that is new code that
would
need to be added.
Well:
On 21 Jan 2022, Julian Foad wrote:
Only for commands that need them, but, as mentioned above,
pesimistically for every file that the command *possibly*
pertains to.
I'll follow up on that.
*nod* Will look for that, thanks.
It will not fetch for 'commit' once I commit Evgeny's tiny patch
to
On 21 Jan 2022, Johan Corveleyn wrote:
I like where this is going. Thanks to all involved for pushing it
forward :-).
You're welcome! Thanks for the use-case example, too.
Any chance your company would want to join the consortium that is
funding this work? Please follow up with my privately
On 21 Jan 2022, Bernard Boudet wrote:
- There should be a single option in the repository config to
define
whether that repo permits client-side plaintext password
storage (or
perhaps define which are the permitted/denied caching methods).
Hmm. A design principle that I think is generally
On 20 Jan 2022, Julian Foad wrote:
The more I think about this, the more I think we are prematurely
complicating the requirements in this respect. I'm going to
back-track
and posit that a simple per-WC switch should suffice for the vast
majority of cases, and has the benefit of simplicity. (The
On 20 Jan 2022, Mark Phippard wrote:
I have made the suggestion before and I want to say there was
agreement from anyone that responded. So if nothing else anyone
that
objects to this is not speaking up. I think the main issue is
that no
one has wanted to step forward and make the change.
I t
On 20 Jan 2022, Mark Phippard wrote:
... my main idea has always been that we put things back the way
they were.
I would be completely in favor of that. The old status quo was
fine: it presented warnings to users at the appropriate moments,
and otherwise let them decide their own threat mode
On 20 Jan 2022, Stefan Sperling wrote:
You may have missed that we have added the 'svn auth' command
while
you were not looking :)
I totally did miss that :-).
Removing cached creds can already be done with 'svn auth
--remove'.
Hah! Now that you mention it, I even remember learning about
On 20 Jan 2022, Dr. Thomas Orgis wrote:
Am Wed, 19 Jan 2022 20:08:06 -0600
schrieb Karl Fogel :
2) Disable plaintext passwords in default runtime
configuration.
Users can re-enable it in their configuration when they want
it.
But when no safe mechanism is available, then 'svn
On 25 Mar 2021, Weatherby,Gerard wrote:
svn-backup-dumps.py is a pretty nice script, but it took way to
look
for me to figure how to put in a post-commit script. Attached is
example.
Thanks for this contribution. It seems good to provide this
example post-commit script, but instead of provid
This thread has been dormant for a while, but the question hasn't
gone away. It would be great if we could reach a consensus. Here
is a combined proposal (based on proposals quoted below from
Daniel Sahlberg and Stefan Sperling):
1) Re-enable plaintext passwords in compile time defaults.
2)
On 19 Jan 2022, Vincent Lefevre wrote:
On 2022-01-13 22:38:34 -0600, Karl Fogel wrote:
So if we have client-side configuration that can specify "no
pristine" based
on some combination of one or more of...
- file size
- repository of origin
- path and/or basename
- svn:mime-typ
On 16 Jan 2022, Branko Čibej wrote:
On 14.01.2022 21:29, Julian Foad wrote:
multi-wc-format branch [...] anything I'm missing?
As soon as I stepped away I could see more clearly: Basically
'multi-wc-format' is just providing an API up to the client
layer for
enumerating WC format variants. The
On 14 Jan 2022, Julian Foad wrote:
I looked into the multi-wc-format branch today. Brane wrote
previously:
This basically needs the following:
* a huge sync with trunk;
Done.
Nice :-). (Understatement is the height of style, ahem.)
Now I'm considering what would be the pros and cons of
On 12 Jan 2022, Julian Foad wrote:
No reason to upgrade an old WC until someone actually wants an
optional pristine.
In principle, an what we ideally desire, agreed. Here I was just
saying
what this branch does as it is now, before being combined with
the
multi-wc-format work, which we're to
On 12 Jan 2022, Julian Foad wrote:
It works as advertised in simple usage:
* pristines are missing until needed (for diff, commit,
revert,
resolve, etc.),
* corresponding disk space reduction
* (and speed differences such as faster checkout, slower
diff)
* fetches pristines
On 11 Jan 2022, Julian Foad wrote:
Hello everyone. Thanks to sponsorship arranged by Karl, I'm able
to work on completing this.
Yay! Very glad you're on board for this, Julian. I should say
that the sponsorship comes from a consortium of several companies
-- Open Tech Strategies LLC (my c
On 31 Jul 2021, C. Michael Pilato wrote:
On Sat, Jul 31, 2021 at 8:16 PM Karl Fogel
wrote:
The use case I started with is:
"Check out a sparse tree, and then check out individual files
--
some of them maybe large binary blobs, others maybe smaller
--
where you need
On 30 Jul 2021, Daniel Shahaf wrote:
Ah, I didn't realize that --depth=files would prune directories
already
checked out. Either we'd have to change that default behavior,
or add a new
depth type... Or maybe the answer is just that
'--depth=directories'
automatically makes those directories st
On 30 Jul 2021, Karl Fogel wrote:
On 30 Jul 2021, Daniel Shahaf wrote:
What would «svn status» of a modified file without a pristine
say?
How many network/worktree accesses would it involve?
Status would say "modified". The client-side still knows the
fingerprint (hash) of th
On 30 Jul 2021, Daniel Shahaf wrote:
Karl Fogel wrote on Tue, Jul 27, 2021 at 20:24:32 -0500:
1) Make pristine text-base files optional. See issue #525 for
details. In
summary: currently, every large file uses twice the storage on
the client
side, and yet for most of these files there&#
On 28 Jul 2021, Nathan Hartman wrote:
Regarding #525, in addition to points discussed previously (i.e.,
that
SVN is strong at large repos and blobs than alternatives, and
#525
would make SVN even stronger in this area), it would improve the
experience for two additional types of users:
* those
Hi, everyone. I'd like feedback an idea that I've had for some
years now but never written up before.
Subversion can already be used to manage large (usually binary)
files. In fact, we use SVN for this at my company and it works
decently. However, there are two possible features that would
$ svn ls -v
https://svn.red-bean.com/kfogel-private/trunk/scratch/bar
9852 kfogelJun 09 13:33 ./
HAH, looks like I accidentally forgot to anonymize one of the
paths when I added that example to my message. Well, now you all
know the secret place -- don't tell anyone :-).
Best regards,
-Karl
On Wed 9 Jun, 2021, 21:23 Karl Fogel,
wrote:
On 09 Jun 2021, Ranajit Ghosh wrote:
>Hi,
>
>I'm writing about the below issue here after not getting any
>particular response about the root cause of it on dev forum.
>
>I'm try
On 09 Jun 2021, Ranajit Ghosh wrote:
Hi,
I'm writing about the below issue here after not getting any
particular response about the root cause of it on dev forum.
I'm trying to do a SVN copy, using URL, the contents from one
directory to another new directory within one repository with the
fol
On 08 Jun 2021, Thomas Singer wrote:
Hi,
A user wanted to copy a working copy to an URL and it fails with
following exception:
org.apache.subversion.javahl.ClientException: Wrong or unexpected
property value
svn: Commit failed (details follow):
svn: Invalid property value
at org.apache.subver
On 09 Mar 2021, Daniel Shahaf wrote:
Thanks for the patch. dev@, anyone wants to review/apply this?
r1887464, and thanks for the poke, Daniel.
The original text was clearly a typo; I confirmed with some
grepping and code exploration. Thanks for the patch, Yutian.
Best regards, -Karl
Yu
On 25 Feb 2021, Yasuhito FUTATSUKI wrote:
Then, I made patches. It also allows pypy to run the test without
'python'. (A) Replace the shebang line of svneditor.py from
svneditor.py
at running the configure
script. (fix-svneditor-in-test-patch-a.txt) As @PYTHON@ can be
basename only, rela
On 25 Feb 2021, Daniel Shahaf wrote:
Daniel Shahaf (Jira) wrote on Wed, 24 Feb 2021 01:52 +00:00:
Daniel Shahaf commented on SVN-525:
--- The one thing I have to
add to Karl's excellent reply [...]
This is a duplicate of a comment I posted in December. I
did
k you, Yasuhito FUTATSUKI, for your further analysis! That
was helpful; I'm glad we have it in the archives.
Best regards, -Karl
On 27 Jan 2021, Yasuhito FUTATSUKI wrote:
On 2021/01/27 16:30, Karl Fogel wrote:
On 26 Jan 2021, Daniel Shahaf wrote:
+1 to using sys.executable. Fixing the q
On 28 Jan 2021, Daniel Shahaf wrote:
You missed one nit: the word "indicates" is still indented just
as much as the parenthesis above it.
Fascinating -- that was deliberate, but as I look through the logs
(here and in other projects), I see that my indentation style has
changed over time too
On 27 Jan 2021, Yasuhito FUTATSUKI wrote:
This is because SVN_MERGE does not execute through a shell, whole
value is treated as a single path. On the other hand, SVN_EDITOR
is passed to system() and is interpreted by a shell.
Ah, thank you for the explanation. What I saw makes sense now.
H
On 27 Jan 2021, Daniel Shahaf wrote:
You're welcome. I see only a few more nits; see below. (Some of
them I noticed in the first iteration too, but I didn't want to
pick too many nits then.) I'm happy that the patch is correct
and committable, though it won't make the "Major features in this
On 26 Jan 2021, Daniel Shahaf wrote:
>+1 to using sys.executable. Fixing the quoting while in there would be
>nice to have, but as it's not a regression it's not a blocker either.
>Happy to leave the details to you.
Well, things turn out to be a bit more complicated than I thought.
My original p
>I'm running the tests right now. If it passes the test suite, and you
>don't see any obvious further to the patch, I'll commit. Thanks again
"obvious further improvements", I meant to say.
-K
Okay, revised patch for review.
I'm running the tests right now. If it passes the test suite, and you
don't see any obvious further to the patch, I'll commit. Thanks again
for your help, Daniel!
Best regards,
-Karl
[[[
Distinguish between regular properties and revprops in tmpfile name.
* sub
On 26 Jan 2021, Daniel Shahaf wrote:
>Karl Fogel wrote on Tue, Jan 26, 2021 at 16:11:31 -0600:
>> This change is useful because many editors display the file's basename during
>> editing (e.g., in a status line somewhere near the bottom of the screen). So
>> if you get i
On 26 Jan 2021, Daniel Shahaf wrote:
>Yay! *gestures* Here's your old chair, right where you left it; I think you'll
>find the only difference from when you last occupied it is that your DHCP lease
>may have expired ;-)
:laugh+cry emoji::)
>AFAICT:
>
>1. SVN_TEST_PYTHON is only used by the
This small patch makes it so that when you do 'svn propedit --revprop', the
tmpfile's name is "svn-revprop-rN.tmp" (where N is the number of the revision
whose revprop is being edited).
For regular properties, nothing has changed: the tmpfile name is still just
"svn-prop.tmp".
This change is u
On 26 Jan 2021, M. Buecher wrote:
>On 2021-01-26 08:47, Karl Fogel wrote:
>> On recent versions of Debian GNU/Linux, the 'python' command doesn't
>> normally exist. Instead, there are separate 'python3' and 'python2'
>> commands.
>
>S
On recent versions of Debian GNU/Linux, the 'python' command doesn't normally
exist. Instead, there are separate 'python3' and 'python2' commands.
As a result, four tests fail in the Subversion test suite as of r1885910, all
for the same reason: the 'subversion/tests/cmdline/svneditor.py' mock
Julian Foad wrote:
>Ah, yes -- I didn't mean to discourage anyone from just describing a
>problem; that can then help others seek a solution. [...]
One thing I wonder is how widely Subversion is in non-published trees,
especially corporate trees.
For example, my company uses Subversion internal
1 - 100 of 138 matches
Mail list logo
