On Tue, Jan 28, 2025 at 10:51 AM Nathan Hartman
wrote:
> >From time to time we get account requests for Jira from members of the
> community. There is such a request now.
>
> Historically we have declined these Jira account requests and directed
> requesters to discuss their issues at the mailing
On Thu, Jun 6, 2024 at 9:25 AM Nathan Hartman
wrote:
> I haven't had a chance to really study this yet (or build or test),
> but the main part of the patch is in ra.c, where
> svn_client__get_youngest_common_ancestor() was calling
> svn_client__get_history_as_mergeinfo(). The patch wraps those ca
On Mon, May 22, 2023 at 2:56 PM Daniel Sahlberg
wrote:
> Hi,
>
> As you all probably know Subversion was initially started by CollabNet and
> several high profile committers have worked there (and some still do).
> However the company's interest in Subversion has decreased over the years
> with s
Was totally surprised while listening to the Corecursive podcast tonight to
hear our old "migrate to git" April Fool's joke listed as a good one. See
https://pca.st/episode/8ca16af6-53c4-4a8f-b879-63988abc1232, starting
around 28:30.
--
Sent via mobile. Please excuse brevity.
Some time ago, I was doing something similar, Mark. If anything from
https://github.com/cmpilato/subversion-dist can be useful to you, feel free
to use it.
On Tue, Mar 29, 2022 at 10:07 AM Mark Phippard wrote:
> If anyone is interested in looking at what I have been doing to run
> the SVN RM pr
WARNING: This is a *total* drive-by post as I skim the thread.
Are there any svn:auto-props syntaxes that are legal .ini but not legal for
auto-props? I'm thinking of the use of a forward slash character. Could
the format be extended such that a key/propname under the [auto-props]
section that
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 them. In many cases, one will simply go into a
> particular d
On Sat, Jun 26, 2021 at 5:12 PM Daniel Sahlberg
wrote:
> Mentioning red-bean.com, it seems that svnbook.red-bean.com doesn't
> support https. I've reached out to Fitz (since I've been in touch with him
> previously) but if someone else read this and pick it up I think it would
> be a good thing.
On Wed, Jun 2, 2021 at 8:20 AM Stefan Sperling wrote:
> ther diff implementations limit the effort spent by aborting after a
> certain number of search iterations, and then simply use the valid
> traversal which was most recently discovered. The libxdiff code used by Git
> does this, as does the
9, 2020 at 10:05 PM Yasuhito FUTATSUKI
wrote:
> On 2020/09/30 10:08, Yasuhito FUTATSUKI wrote:
> > On 2020/09/30 8:51, C. Michael Pilato wrote:
> >> Thanks for the reply. And I see what you're trying to do there, but in
> >> practice it doesn't seem to work. The
ing this construct:
-fs.repos = repos
> +fs.__dict__['repos'] = repos
...and that avoids the AttributeError, but alas the code still SEGFAULTs.
I'm attaching a(n edited for readability) log from a gdb session.
-- Mike
On Tue, Sep 29, 2020 at 4:01 PM Yasuhito FUTATSUKI
wrote
enerator(sys.argv[1], peg_revision, sys.argv[2], pool)
> print(b''.join(generator).decode('utf-8'))
On Tue, Sep 29, 2020 at 9:26 AM C. Michael Pilato
wrote:
> Hey, all. I'm wondering if I can get some extra eyes/brains on a
> particular usage of our Python bind
Hey, all. I'm wondering if I can get some extra eyes/brains on a
particular usage of our Python bindings.
The attached tarball contains a directory in which lives two files:
- run-test.sh - a shell script to drive the reproduction recipe
- pysvnget - a Python program that uses the bindings
On Fri, Aug 21, 2020 at 7:10 AM Daniel Shahaf
wrote:
> C. Michael Pilato wrote on Tue, 18 Aug 2020 10:23 -0400:
> > Sendingsubversion/bindings/swig/include/svn_types.swg
> > Sending
> subversion/bindings/swig/python/libsvn_swig_py/swigutil_py.c
> > Sending
&g
/swig/svn_repos.i
Transmitting file data .done
Committing transaction...
Committed revision 1880967.
I made only minor comment/formatting changes.
On Sun, Aug 2, 2020 at 9:36 AM Yasuhito FUTATSUKI
wrote:
> On 2020/07/31 10:19, Yasuhito FUTATSUKI wrote:
> > On 2020/07/30 22:20, C
t;). But as a concept,
I'd say this part works well.
Does this change anything about the svn_fs_commit_txn() interface?
-- Mike
On Thu, Jul 30, 2020 at 5:00 AM Yasuhito FUTATSUKI
wrote:
> On 2020/07/30 17:47, Yasuhito FUTATSUKI wrote:
> > On 2020/07/29 23:43, C. Michael Pilato wrote
020/07/28 23:34, C. Michael Pilato wrote:
> >>> Hey, all.
> >>>
> >>> I'm writing some code that performs commits via the Subversion Python
> >>> bindings, and I'm struggling to understand some things I see t
Hey, all.
I'm writing some code that performs commits via the Subversion Python
bindings, and I'm struggling to understand some things I see there.
In the svn_fs.i interface file, there's this block of code:
/* ---
Fix the re
On Wed, Jul 8, 2020 at 9:37 AM Daniel Sahlberg
wrote:
> In the original email, I made note of two more pages that I didn't include
> in the patch. Do you have any insight into these or do we need to wait for
> someone else to step in?
>
Sorry, I have nothing to offer on those questions.
>
Sahlberg
wrote:
> Den ons 8 juli 2020 kl 14:34 skrev C. Michael Pilato <
> cmpil...@red-bean.com>:
>
>> Thanks, Daniel. Your patch submission is fine, though I suspect that if
>> in the future you name your patch file such that it ends with ".txt",
>> (evi
On Tue, Jul 7, 2020 at 5:38 PM Daniel Sahlberg
wrote:
> Hi,
>
> I've looked through the website and I propose a few administrative
> changes. It's my first patch so fingers crossed I have not messed up!
>
Thanks, Daniel. Your patch submission is fine, though I suspect that if in
the future you
On Mon, Jun 15, 2020 at 10:32 AM Yasuhito FUTATSUKI
wrote:
> On 2020/06/15 21:38, C. Michael Pilato wrote:
> Is it needed something like this?
>
> [[[
> Index: tools/backup/hot-backup.py.in
> ===
> --- tools/ba
Reviewed, tested, and compared with similar Python3 conversions to other
scripts. All looks good, so committed it:
Sendingbackup/hot-backup.py.in
Transmitting file data .done
Committing transaction...
Committed revision 1878855.
On Mon, Jun 15, 2020 at 4:52 AM Petyovský Petr
wrote:
> H
Minor nit with the patch: I'm not sure that the phrase "Farther version check"
parses clearly. Maybe say, instead:
# Look more closely at the SWIG and Python versions to
# determine SWIG_PY_OPTS. We can skip this if we already
# have the SWIG-generated fil
On Thu, Apr 09, 2020 at 06:09:30PM +, Michael Pilato wrote:
> For your consideration, a patch to allow the creation of release tarballs
> that support py2 bindings (instead of py3 ones).
>
> -- Mike
I don't see why not. Without doubt we will see people trying to compile
S
For your consideration, a patch to allow the creation of release tarballs that
support py2 bindings (instead of py3 ones).
-- Mike
Allow the creation of a release tarball that supports py2 bindings.
* build/generator/gen_make.py
(write_standalone): Allow environmental override of the SWIG_PY_O
Quick confirmation here that at least rc2 contains the SWIG-generated files.
So we're off to a good start! 🙂
From: Stefan Sperling
Sent: Wednesday, April 8, 2020 6:18 AM
To: dev@subversion.apache.org
Subject: Subversion 1.14.0-rc2 up for testing/signing
[EXTERN
Maybe it's just been too long for me, but I thought our releases and release
candidates were supposed to have the SWIG-generated stuff included? I see
those files in, say, subversion-1.13.1.tar.bz2, but not in this new rc1 drop.
From: Stefan Sperling
Sent: Wedne
From: Michael Pilato
Sent: Friday, March 13, 2020 3:03 PM
To: Yasuhito FUTATSUKI ; dev@subversion.apache.org
Subject: Re: A little pre-packaging help, please?
[EXTERNAL EMAIL]
I'm attaching what I used to make this work, which is a Docker-based process.
Just expand the tarball, enter the
I'm attaching what I used to make this work, which is a Docker-based process.
Just expand the tarball, enter the resulting directory, and run
./docker-build.sh.
From: Michael Pilato
Sent: Friday, March 13, 2020 2:49 PM
To: Yasuhito FUTATSUKI
> However as I wrote before[1] it is need to specify SWIG_PY_OPTS
> shell/environment variable to generate SWIG Python bindings C source
> and support codes. The value of SWIG_PY_OPTS depends on which is its
> target py2 or py3, on which SWIG version is prior 4.0 or not.
This was the key thing lac
> https://home.apache.org/~danielsh/subversion-20200311_001/subversion-nightly-r1875088.tar.gz
> https://home.apache.org/~danielsh/subversion-20200311_001/subversion-nightly-r1875088.tar.gz.asc
>
> For future reference, that's the output of «release.py build-env
> trunk-nightly &&
> release.py ro
> While you're waiting for someone to manually roll a nightly tarball, can we
> circle back to the original problem for a minute: What stops you from
> running autogen.sh? Is it just that you'd like someone to figure out
> the list of build dependency package names and configure arguments for
> a
> Unfortunately, it seems that nightly release hasn't updated since
> Feb 28, 2017, as it was reported on users@.
Looks to be the case. svn_version.h carries "1.10.0 (r1784492)".
So ... about that original request, then?
> Hey Mike!
>
> Perhaps a nightly release would work?
>
> https://ci.apache.org/projects/subversion/nightlies/index.html
Yes! Awesome! Thanks so much.
-- Mike
Hey, all!
I've been watching the Python 3.x support shaping up over the course of the
past couple of release cycles, and would like to begin converting ViewVC to
Python3 now that doing so won't immediately have the effect of reverting that
tool to ViewCVSOnly. :-) But I'm having to lay aside
On 11/1/19 12:17 PM, Yasuhito FUTATSUKI wrote:
> My primary purpose to join to develop swig-py3 branch was to see that
> ViewVC officially supports Python 3.
And I'm still watching this (and related threads) with excited
anticipation of your return to that primary purpose. :-)
On 6/18/19 9:50 AM, Paul Hammant wrote:
> Nobody is going to roll up to contribute to 1.x or 2.x Subversion if
> there is no copy-pasteable instructions for building on Mac, Win and
> Linux. And there's not -
> https://svn.apache.org/repos/asf/subversion/trunk/INSTALL - has no
> apt, nuget or h
> On 08.01.2019 19:45, stevek...@apache.org wrote:
>> Author: steveking
>> Date: Tue Jan 8 18:45:45 2019
>> New Revision: 1850781
[...]
>> Modified: subversion/trunk/subversion/include/svn_client.h
>> URL:
>> http://svn.apache.org/viewvc/subversion/trunk/subversion/include/svn_client.h?rev=1850
On 12/13/18 10:45 AM, Branko Čibej wrote:
> Uh. I forgot about the malfunction handler. However this doesn't really
> help, other than putting possibly sensitive paths into the crash handler
> info? We really shouldn't do it this way, users *will* just copy and
> paste the output tot he 'net.
Ahem
On 12/11/18 6:12 AM, Jun Omae wrote:
> On 2018/12/10 22:37, Michael Pilato wrote:
>> Most of the patch is fine. Besides some minor code formatting tweaks,
>> there's only one bit I really changed when committing (as r1848577):
>
> Thanks for the reviewing and tweaki
On 12/8/18 3:57 AM, Yasuhito FUTATSUKI wrote:
> On 12/6/18 5:06 PM, Yasuhito FUTATSUKI wrote:
> Jun Omae kindly reviewed and rewrote my patch to move code to check object
> type into svn_swig_py_make_stream() in swigutil_py.c to minimize expansion
> of typemap, and added test for parse_fns3_invalid
On 12/10/18 7:03 AM, Branko Čibej wrote:
> On 09.12.2018 17:52, Yasuhito FUTATSUKI wrote:
>> Ah, former patch has already been commited. Thank you.
>> I'm sorry I didn't watch trunk.
>
> That's fine! And thank you for your contribution.
>
> If you think your second patch is better, please conside
On 12/3/18 3:15 AM, Julian Foad wrote:
> It makes me uncomfortable to depart from standard parsing. What if
> users are relying on Python ConfigParser or other compatible parsing
> as part of their Subversion authz infrastructure?
We needn't keep this hypothetical. ViewVC is using (a slightly
mod
On 10/27/18 1:12 PM, Branko Čibej wrote:
> On 18.10.2018 20:40, Branko Čibej wrote:
>> On 06.09.2018 15:25, Branko Čibej wrote:
>>> On 06.09.2018 15:10, C. Michael Pilato wrote:
>>>>
>>>> The book carries a cc-by-2.0 license, with Ben, Fitz and mys
On 09/05/2018 04:49 PM, Mark Phippard wrote:
Assuming the PMC wanted it, is it possible for the book to be
contributed to this project and hosted in the Apache SVN repository?
Many people seem to post questions and issues in these mailing lists
as if it is part of the project anyway so maybe we
On 09/05/2018 04:10 PM, Daniel Shahaf wrote:
Can we identify specific tasks that interested volunteers can pick up?
Initial draft:
- Respond to bug reports as they come in
- Liaise with translators
- Add content about from the <1.8/1.9/1.10/1.11> release
- Bring the book up-to-speed with _all_
Hello, all!
It's been a long while since I interacted with any degree of regularity
with this community, and I've had to come to terms with some essential
truths.
First, my time as an active Subversion developer has *definitely*
passed. Oh, I may get a chance to return to it at some point i
On 08/23/2018 09:52 AM, Daniel Shahaf wrote:
We also have a subversion_logo.svg under site/publish/. I'm not sure
why, but the one in notes/ was larger so I chose it.
The one under site/publish was a naive transformation of the original
artwork, which itself used design elements that extended
On 03/23/2018 02:04 AM, Daniel Shahaf wrote:
> Julian Foad wrote on Thu, 22 Mar 2018 22:24 +:
>> This question keeps coming up and I feel we should provide an accurate
>> answer, even if the procedure is not "supported".
>>
>> Any corrections to my current best effort, below?
>>
> As a first s
On 02/12/2018 04:04 PM, Karl Fogel wrote:
> 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?
>
> [[[
> Giv
On 01/25/2018 07:16 PM, Johan Corveleyn wrote:
> Remaining problems:
> * Mapping users works, but only if there is a corresponding account on
> cwiki.a.o. Out of the 24 users that edited pages on our Moin wiki, 17
> don't have a confluence account (3 of which have only made a single
> edit to add t
On 09/14/2017 12:01 AM, Branko Čibej wrote:
> As you may have noticed, I started implementing support for multiple WC
> formats on the better-pristines branch, as a prelude to adding support
> for compressed pristines without forcing users to upgrade all their
> working copies.
Sweet!
> The other
ome book-material.
> More below ... ]
>
> On Thu, Jul 13, 2017 at 6:34 PM, C. Michael Pilato
> wrote:
> > On Thu, Jul 13, 2017 at 11:21 AM, Daniel Shahaf
> > wrote:
> >>
> >> [moving from users@ ]
> >>
> >> Daniel Shahaf wrote on Fri, 30 Ju
With respect to the author and the work he's done, I'm not really
interested in us maintaining yet *another* collection of the same
information already covered -- in some cases multiple times, when you
factor in the reference sections -- by the book. At best this cheatsheet
would be an appendix.
Yes, please do.
On 03/06/2017 10:15 AM, Doug Robinson wrote:
> Folks:
>
> I realize that the SHA1-collision issues are consuming most of the
> duty cycles at this point. Before I forget about this one - should I
> file a bug?
>
> Cheers!
>
> Doug
>
> On Thu, Mar 2, 2017 at 8:19 AM, Doug Robinson
On 01/24/2017 12:01 PM, Daniel Shahaf wrote:
> The bug is about 1.9 using a different order to 1.8. If we make
> svnadmin use the 1.8 unconditionally, then 1.9 will use a different
> order to 1.10, which essentially recreates the bug for other users.
>
> That is: the option serves to allow admins
On 08/11/2016 08:27 AM, Mark Phippard wrote:
> On Thu, Aug 11, 2016 at 8:22 AM, Ivan Zhakov <mailto:i...@visualsvn.com>> wrote:
>
> On 11 August 2016 at 15:17, C. Michael Pilato <mailto:cmpil...@collab.net>> wrote:
> > On 08/10/2016 08:44 AM, Ivan Zh
On 08/10/2016 08:44 AM, Ivan Zhakov wrote:
> Serf doesn't support Windows 2000 (due direct usage of SSPI).
>
> Given all above I propose to officially drop Windows 2000 support in
> Subversion and cleanup some Windows 2000 compatibility code.
Does this mean I need to upgrade my only Windows machin
Migration off of Tigris.org and onto ASF Jira seems the smartest option for
this project. +1
On Tue, Sep 15, 2015 at 5:59 AM, Bert Huijben wrote:
> Hi All,
>
>
>
> Here at the hackathon in Berlin we are discussing issue trackers, and more
> particular how we should eventually mo
Simply pop a mail off to dev-unsubscr...@subversion.apache.org, Katherine.
On Thu, Sep 10, 2015 at 3:07 PM, Katherine Sheehan
wrote:
> I'd like to unsubscribe to this mailing list please.
>
> Kind regards,
> Katherine
>
_description’ which uses ‘
> svn_wc__external_description_format_1’ and ‘
> svn_wc__external_description_format_2’ to handle the different formats.
>
>
>
> (In the pre 1.5 format the ‘-r’ is interpreted as a peg revision)
>
>
>
> Bert
>
>
>
> *From:* C
I was reading up on the new 'svn cp --pin-externals' feature in the 1.9
release notes. Great addition, by the way, and one that I hope to use
myself with ViewVC's release tags.
One question came to mind, though. The use of the feature appears to
result in pegged externals definitions (as in, @-b
On 05/14/2015 08:12 AM, Branko Čibej wrote:
> On 13.05.2015 15:24, C. Michael Pilato wrote:
>> I lean towards thinking that falls outside the scope of acceptable
>> changes in behavior in the 1.x line *unless* you can find a way to,
>> via configuration, allow administrators
On 05/13/2015 10:35 AM, Branko Čibej wrote:
On 13 May 2015 at 15:24, C. Michael Pilato
wrote:
Well, the use-case being broken here is kinda the obvious one: I
shouldn't have permission to create/delete some path /foo/bar (it's a
system-critical file that shouldn't go away
On 05/13/2015 02:21 AM, Stefan Fuhrmann wrote:
> Hi devs,
>
> At WANdisco, people have been playing with the new
> wildcard support for authz (see authz-performance branch)
> and ran into an interesting problem.
[Details snipped. Welcome to 2004, where CollabNet ran into the same
issues with the
le
resource differently than the somewhat unavoidable implicit attempts.
As for log levels, is there any reason to log the implicit read attempts
at a level higher than "debug"? I have no opinion about the log level
for the explicit ones.
--
C. Michael Pilato
CollabNet <> www.collab.net <> Enterprise Cloud Development
ry.
Alas, I haven't the time to devote any real attention to your patch or
subsequent iterations thereof. But I thought I'd at least respond with
a bit of encouragement.
--
C. Michael Pilato
CollabNet <> www.collab.net <> Enterprise Cloud Development
On 12/01/2014 12:04 PM, Alexey Neyman wrote:
>
> On 12/01/2014 06:17 AM, C. Michael Pilato wrote:
>> Just a quick question, as my bindings knowledge has grown somewhat
>> stale: why do some of the wrapper functions use a format string with
>> the tuple notation (e.g., &q
On Mon, Dec 1, 2014 at 2:24 AM, Alexey Neyman wrote:
> Hi all,
>
> Please review/comment.
>
Just a quick question, as my bindings knowledge has grown somewhat stale:
why do some of the wrapper functions use a format string with the tuple
notation (e.g., "(O)") and others not (e.g., "Oss#O&")?
I
On 10/01/2014 10:16 AM, Philip Martin wrote:
> Philip Martin writes:
>
>> "C. Michael Pilato" writes:
>>
>>> The log message for r2419 mentions "files" larger than 4Gb, and leads me
>>> to believe that this problem only affects GETs. But
On 10/01/2014 06:48 AM, Philip Martin wrote:
> Andreas Stieger writes:
>
>> I
>> will once again point to the serf issues below and httpd/network config.
>> https://code.google.com/p/serf/issues/detail?id=152
>> https://code.google.com/p/serf/source/detail?r=2419
> Andreas identified a bug in serf
to actually review it. I don't think there is any
> point in rushing a decision at this stage of 1.9 "slippage".
>
> -- Stefan^2.
I'm late to the party, but this all sounds great.
--
C. Michael Pilato
CollabNet <> www.collab.net <> Enterprise Cloud Development
#x27;s behavior without a driving
use-case beyond mere developer OCD seems like a waste of time of
energy. That said, it's neither my time nor energy at risk, so weigh my
input accordingly.
--
C. Michael Pilato
CollabNet <> www.collab.net <> Enterprise Cloud Development
, which is
trying its darnedest to act like a repos-layer dump/load driver but sits
on the other end of the higher RA layer?
--
C. Michael Pilato
CollabNet <> www.collab.net <> Enterprise Cloud Development
ng that we knew what
information did and didn't matter to an administrator. This is why
svn_fs_props_changed() and svn_fs_contents_changed() never bothered to
compare the respective prop/text content, but merely noticed that the
DAG had or hadn't been adjusted.
--
C. Michael Pilato
C
On 09/18/2014 08:26 AM, Ivan Zhakov wrote:
> On 11 September 2014 18:03, C. Michael Pilato wrote:
> Mike,
>
>> Ivan: As a reviewer of the code in question, there's really no way
>> you could have established (for yourself) a legitimate objection
>> about the "
On 09/10/2014 05:37 PM, Branko Čibej wrote:
>
>
> > I have technical objections related to the general quality of the
> > new code. The best way to find out more is to review this code by
> > yourself!
>
> No. It's your veto and therefore the burden of evidence is on you.
> "General quality of code
On 09/10/2014 01:06 PM, Stefan Sperling wrote:
> I've been working on the log-message-templates branch recently.
> This branch was started by cmpilato a long time ago but for some
> reason sat around untouched ever since. It's now been overhauled
> by me with much help from Bert.
Just for a bit of
"transaction props" and "revision props" once we get outside our API
space and into user command space. Our users understand "revision
props" as properties on revisions, and transactions as revisions-to-be
... the rest is fairly trivial inference.
(And yes, 'svnlook' should be kept read-only.)
--
C. Michael Pilato
CollabNet <> www.collab.net <> Enterprise Cloud Development
On 09/05/2014 08:03 AM, s...@apache.org wrote:
> Author: stsp
> Date: Fri Sep 5 12:03:35 2014
> New Revision: 1622687
>
> URL: http://svn.apache.org/r1622687
> Log:
> On the log-message-templates branch, change the contents of the
> log message template hash table passed to API consumers.
FWIW, I
On 08/26/2014 09:02 AM, Stefan Fuhrmann wrote:
> Personally, I'd be fine with renaming it. Others think
> we shouldn't do it because of "released". Realistically,
> we will break hardly anybody's setup by renaming it.
+1.
> Note that we
> never include such headers in current Subversion c
On 08/19/2014 09:27 AM, Stefan Fuhrmann wrote:
> On Tue, Aug 19, 2014 at 3:19 PM, C. Michael Pilato <mailto:cmpil...@collab.net>> wrote:
>
> On 08/19/2014 09:12 AM, stef...@apache.org
> <mailto:stef...@apache.org> wrote:
> > Author: stefan2
>
On 08/19/2014 09:12 AM, stef...@apache.org wrote:
> Author: stefan2
> Date: Tue Aug 19 13:12:48 2014
> New Revision: 1618860
>
> URL: http://svn.apache.org/r1618860
> Log:
> Move svn-bench from ./tools into ./subversion.
>
> * tools/client-side/svn-bench: Move from here to ...
> * subversion/svn-
On 07/29/2014 06:46 AM, Branko Čibej wrote:
> If we want to
> support wildcards, we /have/ to invent a different syntax for wildcard
> rules. My working proposal is to add a literal '*' before the leading
> slash in the path:
>
> [*/fspath-pattern]
> [repos:*/fspath-pattern]
>
> because n
On 07/07/2014 11:23 AM, Branko Čibej wrote:
> On 07.07.2014 17:07, C. Michael Pilato wrote:
>> On 07/07/2014 10:58 AM, Ivan Zhakov wrote:
>>> My technical opinion that FSFS7/log addressing is slower by design,
>>> because it's doing more (read index, then read da
x27;m coming into this kinda late and after two weeks of vacation, so
please forgive me if I misunderstand the above, but is it true that
FSFS7 requires some kind of non-trivial caching just to match FSFS6's
performance?
--
C. Michael Pilato
CollabNet <> www.collab.net <> Enterprise Cloud Development
tput that surely *countless* scripts have already been written to parse.
--
C. Michael Pilato
CollabNet <> www.collab.net <> Enterprise Cloud Development
e to me. In fact it sounds like an oversight that
> we didn't offer this originally.
IIRC, this was an intentional omission, as we knew that lock handling
would be terribly inefficient and that directory locks weren't supported.
--
C. Michael Pilato
CollabNet <> www.collab.net <> Enterprise Cloud Development
On 04/07/2014 11:10 AM, Branko Čibej wrote:
> On 07.04.2014 09:06, C. Michael Pilato wrote:
>> On 04/07/2014 10:58 AM, Ben Reser wrote:
>>> Let's adopt Johan's suggestion from the other thread.
>>>
>>> Specifically, for alpha/beta releases (no change
On 04/07/2014 10:58 AM, Ben Reser wrote:
> Let's adopt Johan's suggestion from the other thread.
>
> Specifically, for alpha/beta releases (no change for release candidates or
> normal releases). Require at least 1 vote for each platform (Windows/Unix)
> and
> at least 3 votes total.
Quick clar
t is the DB_REGISTER subsystem which
enforces that. I assume that what's happening is that your process
opens the original repository, copies the repository (which carries with
it the db.register file), and then upon trying to open the copied
repository runs into problems because BDB sees the
On 03/19/2014 11:12 AM, Bert Huijben wrote:
> Just to name a few: to set our binary properties, which we documented to just
> allow '*'
>
> svn:needs-lock
> svn:executable
This is a kinda soft one, since we automatically normalize the values of
these properties:
$ svn pset svn:executable '' io
ms was a major design goal from the
project's beginning.
--
C. Michael Pilato
CollabNet <> www.collab.net <> Enterprise Cloud Development
he deeznits.
Others dislike the inconsistency, and prefer instead:
* build/ac-macros/serf.m4:
(): Update the description.
(some_func): Twiddle the deeznits.
Once you establish a habit of the latter, it sorta follows that when you
have only top-level changes, you stick with your established pa
On 02/24/2014 01:56 PM, Philip Martin wrote:
> Thomas Åkesson writes:
>
>> Svn does not allow locking non-existent paths. It is blocked both in
>> libsvn_fs_base/libsvn_fs_fs as well as in mod_dav_svn. In the same
>> areas of the code in fs comments say:
>> "While our locking implementation easily
On 02/05/2014 05:45 AM, Julian Foad wrote:
> C. Michael Pilato wrote:
>
>> Mostly looking
>> for general feedback on the idea of the "sounds useful if it works" or
>> "you *really* don't want to go there" variety, but deeper review is of
&
Didn't want to commit this directly just yet, given my somewhat
disconnected attention level in the project as of late. Mostly looking
for general feedback on the idea of the "sounds useful if it works" or
"you *really* don't want to go there" variety, but deeper review is of
course welcome, too.
On 01/10/2014 02:00 PM, Ben Reser wrote:
> Wish that cleaning up pristines hadn't been overloaded into cleanup. Ran into
> a situation where I crashed the client today. So I needed to run cleanup, but
> I hadn't run cleanup in a very long time so of course it took a while since it
> also went thr
On 12/17/2013 10:06 AM, C. Michael Pilato wrote:
> Just piping in on this one point. POST is perfectly acceptable here,
> and is not in conflict with the DAV spec in the least. Just because we
> add a new route for locking/unlocked multiple paths (via POST) doesn't
> mean we&#
1 - 100 of 1804 matches
Mail list logo
