Daniel Shahaf writes:
>Daniel Trebbien wrote on Fri, Sep 10, 2010 at 12:24:29 -0700:
>> After applying my patch and recompiling `svnsync`, QA can test with
>> the script at: http://pastebin.com/g0n9uqYr
>
>QA? That's not how open source works :-)
>
>Daniel
>(re QA remark, I couldn't find an appr
"C. Michael Pilato" writes:
>A hearty +1 to all of what you've indicated!
Likewise!
>Additionally, in 2010, I'd like to work with other devs that care to restore
>some sense direction to this product. At a
minimum, that means identifying
>and killing the bugs and misfeatures that are impeding
"Hyrum K. Wright" writes:
>Because we are a large and mature project, there is also a certain
>amount of maintenance cost just to maintain parity with ourselves and
>other SCM systems. Our ever-increasing list of outstanding issues
>witnesses to the fact that we aren't very good at maintaining th
Mark Mielke writes:
>I think this is only true in the sense that more users have a better
>chance of exposing existing problems. (Assuming the 'bugs' are actual
>bugs' and not feature requests)
>
>More bugs means more technical debt, which means less efficiency for
>the entire project over time. A
Not sure of the proper place to report this, and subversion.apache.org
doesn't say (which is in itself a bug, though one that's likely to get
fixed soon), so I'm posting here (in case it helps for anyone to know),
and I'll post separately to Apache's infrastructure list.
In Firefox 3.5.6, I visite
Ed writes:
>Correction. Now I know how to reproduce this.
>
>Select the first link. Right click on one message (any one will
>do) and the select Open in New Tab or Open in New Window. Then
>presto, what is seen in the second link.
>
>Is it a bug, or is it just the actual display of what the
>li
"Hyrum K. Wright" writes:
>You may also want to contact the mod_mbox folks:
>http://httpd.apache.org/mod_mbox/
Done.
Karl Fogel writes:
>"Hyrum K. Wright" writes:
>>You may also want to contact the mod_mbox folks:
>>http://httpd.apache.org/mod_mbox/
>
>Done.
To be clearer: https://issues.apache.org/bugzilla/show_bug.cgi?id=48500
-K
Mark Mielke writes:
>On 01/04/2010 06:46 PM, Karl Fogel wrote:
>> "Hyrum K. Wright" writes:
>>> Because we are a large and mature project, there is also a certain
>>> amount of maintenance cost just to maintain parity with ourselves and
>>> o
iting code (sadly)! :-)
-Karl
>- Original Message ----
>> From: Mark Mielke
>> To: Karl Fogel
>> Cc: Hyrum K. Wright ; Mark Phippard
>> ; Subversion Dev
>> Sent: Sun, January 17, 2010 10:31:47 AM
>> Subject: Re: Subversion in 2010
>>
>> On 01/17/2010 0
Ben Collins-Sussman writes:
>And happy birthday to Karl Fogel and Sander Striker as well. :-)
I'd say Subversion is wearing its years better, but thanks :-).
-K
>On Tue, Feb 23, 2010 at 7:34 AM, Giulio Troccoli
> wrote:
>>> On this day six years ago, and after spending
neels writes:
>The intention is to allow people that just joined or were split for a
>few minutes to read some backscroll. Also, when someone said something
>useful, I'd like to be able to get it back (without having to ask
>kfogel for his log).
Indeed -- I'm only logging when I'm on the Net and
"C. Michael Pilato" writes:
>projecting a bit into the future what we'd like to see Subversion become, we
>offer the following vision statement for your review:
>
> Subversion exists to be universally recognized and adopted as an
> open-source, centralized version control system characterized
Mark Slade writes:
>Per your Issue Tracker Guidelines, I am seeking somebody who agrees
>that this is a bug before I submit it.
>
>Overview: For files, 'svn mv' does not properly inherit ACL
>permissions from the parent directory.
>
>Steps to reproduce (from a subversion working directory):
>1. se
André Colomb writes:
>After some more testing, I have found another problem with the
>svn-status mode in psvn.el. The attached patches extend on the previous
>one to also make ediff-mode work again with psvn.el.
>
>[...]
>
>The previously proposed patch by Koji Nakamaru addressed an error when
>tr
Daniel Shahaf writes:
>FYI Karl: http://svn.apache.org/r1410697
>:-)
Oh, thanks! And here I thought I was all thorough because I managed to
catch the original commit (r872864) as well as the merge commit
(r873216)... but I didn't think to look in the regression tests. Nice.
You might be amused
It's been a while, so out of caution I'd appreciate review on this
before I commit, even though it's a fairly trivial patch. Thanks!
[[[
Bring the SQLite amalgamation download instructions up to date.
* configure.ac
(SQLITE_AMALGAMATION_URL): New name for SQLITE_URL. Also new value,
becau
Daniel Shahaf writes:
>Daniel Shahaf wrote on Fri, Oct 28, 2011 at 09:19:37 +0200:
>> Karl Fogel wrote on Thu, Oct 27, 2011 at 23:28:43 -0400:
>> > It's been a while, so out of caution I'd appreciate review on this
>> > before I commit, even though
"Daniel Shahaf" writes:
>We could construct the URL as currently valid and also link to the
>download page. That way people can click the first link and also have
>the second if the first breaks.
But the version-specific URL is going to be invalidated so quickly that
most of the time (probably,
"Bert Huijben" writes:
>> Given the fine granularity of the version numbers, it seems likely that
>> Richard Hipp updates the "latest amalgamation" zipfile fairly often. We
>> could ask him to keep the old versions in place, but that seems like a
>> lot of trouble to go through, given that the la
'Daniel Shahaf' writes:
> './get-deps.sh sqlite' works for me, right now.
When you run configure, if it can't find the right SQLite it prints out
a message with a URL where you can fetch it. Last night, when I did
this, that message was wrong -- the URL it pointed to didn't exist.
That was what
'Daniel Shahaf' writes:
>Yes. And I'm saying that we already have the correct URL elsewhere
>in the code.
>
>Anyway: we're looping, since I already made that point and I already
>understand what problem you were trying to fix. Why don't you just fix
>it, one way or the other? Neither of us want
Paul Hammant wrote:
> http://paulhammant.com/2014/02/03/facebook-scaling-mercurial-for-trunk-based-development
> -
> (scroll down half way).
>
> I'm a user of Subversion from about 0.7 onwards (via Codehaus). I was at
> the 1.0 party in Brisbane, CA many tears ago. Like Perforce, Svn is still
> ou
Daniel Shahaf writes:
>r6881 implies that a ^/clients directory existed until r6880:
>https://svn.apache.org/viewvc/subversion/README?r1=846955&r2=846954&pathrev=846955&diff_format=f
>
>kfogel on IRC recalls it having existed.
>
>However, the ASF repository does not have a ^/subversion/clients tre
Greg Hudson writes:
>I remember svn (the command) living under subversion/clients/svn and
>being moved to subversion/svn.
That's "/trunk/subversion/clients/", which we also discussed in IRC, but
is separate from "/clients" (note the lack of "trunk/").
>If there's no evidence of this in our Subve
Ivan Zhakov writes:
>On 26 April 2016 at 10:58, Stefan Sperling wrote:
>> Hi Karl,
>>
>> On IRC, you asked:
>>
>>stsp: Is there anyone still in Patch Manager role in the project?
>>I just saw this, http://jk.ozlabs.org/projects/patchwork/, and thought it
>>might be helpful.
>> * kfo
5bc6e4e org/main.org-from-repository-r6916
$ diff -u org/main.org org/main.org-from-repository-r6916
--- org/main.org 2017-07-27 01:01:36.259540030 -0500
+++ org/main.org-from-repository-r6916 2017-07-27 01:03:19.472775400
-0500
@@ -9,6 +9,7 @@
To: Karl Fogel
Da
itory-r6916
> $ diff -u org/main.org org/main.org-from-repository-r6916
> --- org/main.org2017-07-27 01:01:36.259540030 -0500
> +++ org/main.org-from-repository-r6916 2017-07-27 01:03:19.472775400
> -0500
> @@ -9,6 +9,7 @@
>To: Karl Fogel
>Date: W
Philip Martin writes:
>The post-commit processing on the client side is not checking for
>modifications before recording filesize/timestamp in the nodes table in
>.svn/wc.db.
My hat is off to you for tracking this down, Philip! Thanks.
Comments/questions at the end, after your transcript.
>In
"Bert Huijben" writes:
>There used to be a system for this around the release of Subversion 1.7.0.
>Not sure what happened to this...
>There should be a comparison (probably via one of the wc question apis) if
>the timestamp changed since what was committed.
There is no need to do such a check at
I filed https://issues.apache.org/jira/browse/SVN-4708 about this (after
searching to see if anything had already been filed about it).
Best regards
Karl
Philip Martin writes:
>Karl Fogel writes:
>
>> Am I missing some subtlety about this?
>
>I think you are correct. I
Hi all. I think one of the import error messages in
tools/hook-scripts/mailer/mailer.py is misleading (I discovered this while
debugging the problem that Troy Curtis Jr. solved in r1823802). Any objections
if I install this patch?
[[[
Give correct error message on failure to import Subversion
Daniel Shahaf writes:
>It would be useful to also print the caught exception in case it contains more
>specific information about the cause of the problem…
>
>… but in that case, why not remove the try/except entirely?
That's a good point. I already committed my original proposed change in
r182
There are possibly two bugs here, one of them supremely weird. The attached
script shows the recipe, with commentary.
(This is all with svn version 1.10.2 (r1835932) as packaged in Debian GNU/Linux
for x86_64-pc-linux-gnu.)
The rest of this mail will assume you've run, or at least examined, th
Daniel Shahaf writes:
>Karl, this part is entirely normal.
>
>When you do «echo bar > qux», your shell calls open(O_TRUNC), not
>unlink(). In your case, since new-foo is a symlink on disk, when you do
>«/some/command > new-foo», your shell calls open(O_TRUNC) on new-foo and
>writes the command's
Daniel Shahaf writes:
>However, in higher layers, that do know of svn:special's semantics, I
>don't know if it makes sense to allow a node to change type from "file"
>to "symlink". Note that we added svn_node_symlink to svn_node_kind_t
>(in 1.8) as a distinct value; the thinking then, IIRC, was t
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
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
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
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, 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
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
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
>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
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
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 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 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
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 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
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 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 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 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
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
$ 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 :-).
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
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
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 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:
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 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 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 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 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 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 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 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
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 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
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 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, 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, 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, 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 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 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, 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, 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, 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 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 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 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 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
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 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
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 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 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:
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.
-
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 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'
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 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 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 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:
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 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 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 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
1 - 100 of 138 matches
Mail list logo
