Re: Sparse checkouts suggestion

> > > foo.py: > > import os > def my_mocked_os_system(*args, **kwargs): > print('a mockery') > os.system = my_mocked_os_system > > > bar.py: > > import os > os.system("echo bar") > > import foo > os.system("echo foo") > > > Then: > > $ PYTHONPATH=. python bar.py > bar > a mockery > > I've

Re: Sparse checkouts suggestion

Would I retain the previous value of os.system and set it back after any assertions (pass or fail) so that following tests would not affected? Or does it und itself naturally when Pytest recurses in the next test in its suite ? As I hinted I couldn't find such an example online, with an emphatic

Re: Sparse checkouts suggestion

> > Yes, that one's pretty nice, but as a rule we try not to burden our > users with dependencies outside the standard library. The script uses > os.system, what, twice? Hardly worth replacing. > > On the other hand, we have wrappers around subprocess.Popen in >

Re: Building Subversion.

> > > > If yes, do you have the homebrew installables you needed handy? > > #LemmeKnowPls > > "brew install subversion"? > > I've done't that already, but I'm switching hats from 'user' to 'developer' of subversion. The brew installables I was thinking of were the development pre-requisites for

Re: Sparse checkouts suggestion

My aim was to minimally impact the prod source. The context object is a good idea. I've been using https://amoffat.github.io/sh/ and quite enjoying it for my other python/svn project.

Re: Sparse checkouts suggestion

I ran pep8 over the sources and thought I'd remediated all the training spaces already. I'll finish the job. My alternative to the four globals is to pass the function pointers as parameters through one or two intermediates to the functions that would use them. Would that be acceptable? I can't

Re: Building Subversion.

The needs of the book are different to the needs of the Svn project. And the needs of the project are far more important than one of a few Svn books. I'm going to stand by what I said. -ph

Building Subversion.

The tests made for https://github.com/apache/subversion/pull/5 didn't even require me to have Svn on my system. That's because I'm asserting against a series of expected shell operations, because that's how the author implemented svn-viewspec Has anyone built Subversion on a Mac? If yes, do you

Re: Sparse checkouts suggestion

Thanks. Here's what I expect to land - https://github.com/apache/subversion/pull/5 Ten tests - ten passing in less than 0.1s I don't know if there is a clean workflow from Git commits back into Subversion so, I'll make the same commit through the Svn HTTPS interface, if code review comments are

[GitHub] subversion pull request #5: pytest tests for svn-viewspec

GitHub user paul-hammant opened a pull request: https://github.com/apache/subversion/pull/5 pytest tests for svn-viewspec You can merge this pull request into a Git repository by running: $ git pull https://github.com/paul-hammant/subversion trunk Alternatively you can

Re: Sparse checkouts suggestion

OK, so I am up at 93% coverage with a PyTest script. As an Apache Member I'm already CLA'd. I could start to write tests that break the script in ways that it should handle more gracefully, but I need assurance that I'm not wasting my time. I'm not expecting committership (especially since my

Re: Sparse checkouts suggestion

T'was line endings and redundant spaces, fixed with a strip(), but as I say, Java's asserts are better to noobs. Here's the test: https://gist.github.com/paul-hammant/058161485a227299e5d7c34cc6a33264 I had to refactor the actual script too. A tiny backwards-compatible bit. -ph

Re: Sparse checkouts suggestion

I have a test for the inlined example. Well it would pass, but PyTest's assert function is about 10x inferior to JUnit's or Hamcrest's assertEquals() and isn't telling me where I've futzed up a CR somewhere. This even *with* optional args (that should be mandatory -s and -vv). Gotta go to work now

Re: Sparse checkouts suggestion

Oh tools/client-side/svn-viewspec.py doesn't have any tests :-( The good news is that it can be refactored to have test quite easily. I think I'll be able to donate some code.

Re: Sparse checkouts suggestion

> > > http://svn.apache.org/repos/asf/subversion/trunk/tools/ > client-side/svn-viewspec.py > > Excellent! I see you posted a StackOverflow answer on that too, Mark - https://stackoverflow.com/questions/7481860/create-folder-structure-based-on-file I'm one of those people that's blind to a lib

Re: Sparse checkouts suggestion

> > This is an old idea. If you want to implement it, a file is not the > > right place for the view definition; a property on a directory > > might be. > > > > > > A Svn property that sets for the user and workspace only, and retains > > no history, right? Meaning if the user had two

Re: Sparse checkouts suggestion

> > This is an old idea. If you want to implement it, a file is not the > right place for the view definition; a property on a directory might be. > A Svn property that sets for the user and workspace only, and retains no history, right? Meaning if the user had two checkouts of the same Svn URL,

Sparse checkouts suggestion

: 1. https://paulhammant.com/2014/01/06/googlers-subset-their-trunk/ (based on 2009 memories). Yes I know they are in Piper now and out of Perforce. 2. Previously I forked a medium-sized Monorepo on Github, and did the the complete expand/contract work for it - https://github.com/paul- hammant

Re: Shelving / Checkpointing thoughts

> > Apache products aren't allowed to depend on GPL'd code for mandatory / > core features. > Even GPL2 with the linking exception? > What is the advantage of linking to libgit2 over simply telling users to > use git-svn with 'git stash' and local branches? > None, assuming you've learned the

Re: Shelving / Checkpointing thoughts

Fully expecting this to have a popularity of -5 on a 0 - 10 scale, I thought I'd share that I'm progressing with a "subversion shelve" tech on GitHub, that uses Git for the Shelve/unshelve (making a single 'bundle' blob) :- https://github.com/paul-hammant/svn-shelve Pull Requests welc

Re: Shelving / Checkpointing thoughts

Here's a prototype in Python2 that makes a git repo in a 'shelve' folder. Two commits - one with the starting position, and one with the ending position. The 'svn info' for the resource is copied in too (same file name with a '.info' suffix). import sh import os from stat import S_IWUSR, S_IREAD

Re: Shelving / Checkpointing thoughts

Perhaps easy to prototype in Python, too.

Re: Shelving / Checkpointing thoughts

Delegating to libgit2 to invisibly handle: shelves, local-branches and pull-requests could yield a workable and flexible implementation. Pull-requests flow back to the central repo, of course) and there interactive and automatic workflows include: code review, classic CI, linting and other

Re: Benchmarks for PUT for various fsfs config settings.

http://imgur.com/a/vVKSx This one is the original 128MB PUT test but on a Raspberry Pi Zero W (client and server). Raspbian is based on Debian Jesse which uses Svn 1.8.10. The Zero has 512MB RAM and a 1Ghz ARM chip (the same spec as the original Pi). Performance was 1/6 of the CHUWI HiBox Smart

Re: [RFC] Using LZ4 compression by default

Wouldn't the svn client just speculatively specify a HTTP "Accepts" header with requests up to the server? You'd be able to do back/forwards compatibility with that, and not have to change any other wire spec ?

Re: Proposal - option to store unzipped office documents on server side.

le zip itself compresses all files independently. Not related to Svn, but elsewhere I was working towards Maven Jars in Git, too .. *"Github releases as a Maven repo" * So I have 27 releases of XStream unzipped and pushed to https://github .com/paul-hammant/mc-xs-classes In terms o

Re: Proposal - option to store unzipped office documents on server side.

> > > You are not the first to ask for this, but it is significantly more > complex than just a backend setting. [] > Yup, I didn't think about the SHA1 being different. I'll implement it client-side, just ignore this request. -ph

Proposal - option to store unzipped office documents on server side.

I understand the process to propose feature requests is to first post the idea on this forum, then if everyone agrees, post an item to Jira. I previously wrote a blog entry on Git storing MsOffice document unzipped (.docx and .xlsx are zips XML and a few things) -

Re: Benchmarks for PUT for various fsfs config settings.

Markus, Yes, leaving rep sharing enabled is better for another reason that a file sync agent is *likely* to encounter: someone renames a directory. Remember I'm not using Subversion client tools to effect a commit. But... >. Rep sharing brings its real benefits when equal files are stored >

Re: Benchmarks for PUT for various fsfs config settings.

> > > Here it is - http://imgur.com/a/vBeKi - a more interesting graph. > Note that was 4 iterations, not 6 (as before). Server side Storage Used (MB): Default: 129 No_Compression_No_Deltification: 257 No_Deltification_No_Rep_Sharing: 513 No_Compression_No_Deltification_No_Rep_Sharing: 513

Re: Benchmarks for PUT for various fsfs config settings.

> > Next up - larger files where the second has a mid-section that changes for > a few bytes, vs the first. > Here it is - http://imgur.com/a/vBeKi - a more interesting graph.

Re: Benchmarks for PUT for various fsfs config settings.

Alternate file sizes - still pretty much every byte different between the two alternately uploaded files: 24MB - http://imgur.com/a/kPyY8 4MB - http://imgur.com/a/uRaW8 Next up - larger files where the second has a mid-section that changes for a few bytes, vs the first.

Re: Benchmarks for PUT for various fsfs config settings.

I'll re-run for smaller sizes (and yes that 128GB was a typo) Things won't be not so separable that way, IIRC.

Re: Benchmarks for PUT for various fsfs config settings.

If I can manage to build the LZW compression version of the forthcoming v1.11 Subversion, I'll put that in the mix as a permutation to test. Is anyone interested in the Python harness for these integration tests? - Paul

Benchmarks for PUT for various fsfs config settings.

Chart: http://imgur.com/cKe2l4J In Python I made two 128GB random files, then uploaded them alternately six ties three each to the same endpoint in Svn over DAV. That would be a run. After wiping the server repo and repeating that, I performed four runs all in all. For each datapoint, I

Re: Proposal: mod_authz_svn to get an option to inform clients that resource 'cannot be written to'

OK, I've added https://issues.apache.org/jira/browse/SVN-4691 I've tried to focus on the meat of the ask, and cover previous questions. Also I've covered previous suggestions, though while welcome, would not solve the same problem.

Re: Proposal: new fsfs.conf properties

> > A couple of tests show that it's possible to get up to 2x speed improvement > when importing large binary files, although the actual improvement will > vary, depending on the configuration of the server and the client. And, > apart from this, such imports won't be using the free space in

Re: Proposal: mod_authz_svn to get an option to inform clients that resource 'cannot be written to'

May I go ahead and raise the feature request in Jira now? I believe the approved process was discuss on mail-list, then raise in Jira. - Paul On Fri, Jul 21, 2017 at 5:40 AM, Julian Foad <julianf...@gmail.com> wrote: > Paul Hammant wrote:> It will help the owners of subv

Re: Proposal: mod_authz_svn to get an option to inform clients that resource 'cannot be written to'

> > > What is the story? How is this going to help Subversion users? > > The idea sounds interesting. However, I'm not sure how it will help > the users. I don't mind whether I have Read Only or Read / Write > access to an FTP resource or another kind of remote data. I just know > whether I have

Re: LZ4 compression

Evgeny wrote: Speaking of only using it with compression level 1, that's not a starting > point. While LZ4 offers superior speeds, it is not a substitute for any > zlib compression level > 1, including our current default of 5, as the > latter gives better compression ratio. > > I was thinking

Re: Proposal - Optional JavaScript include in "Powered by Apache Subversion..." pages

> > See the SVNIndexXSLT directive. You can do pretty much whatever you like > with the directory listing. > Near perfect. I'll blow the dust off my XLS skills (unused for 16 years).

Proposal - Optional JavaScript include in "Powered by Apache Subversion..." pages

The page I'm talking about is the skinny one that presents directory listings: svnRepo1 - Revision 195: / svnRepo1 - Revision 195: / .. a/ Powered by http://subversion.apache.org/;>Apache Subversion version 1.9.5 (r1770682). It would be super awesome to be able to administrators of

Re: Proposal: new fsfs.conf properties

I think as this thread draws towards a close, that the lz4 modifictions Evgeny made in part address my speed concerns for gigabyte sized files. And that if any more speed for PUT is wanted, that one would set: max-deltification-walk = 0 compression-level = 0 It also looks like the there is

Re: Proposal: new fsfs.conf properties

Philip, > Ah, it's not running out of space in tmp, rather it is failing to find > tmp. There is a behaviour difference between Subversion 1.9 and 1.10 > here: each Apache child process using 1.9 will create two zero-length > files in tmp, the first is APR finding tmp the second is Subversion >

Re: Proposal: new fsfs.conf properties

f 64GB SSD. - Paul On Fri, Jul 14, 2017 at 4:42 PM, Philip Martin <phi...@codematters.co.uk> wrote: > Paul Hammant <p...@hammant.org> writes: > > >> I don't believe Apache/mod_dav_svn uses TMPDIR when processing a PUT. > >> > > > > I can prove that e

Re: Big files PUT into Subversion - encountering

4.10.0-26-generic More than you asked for, but more specs: OS: Ubuntu 17.04, server Processor: 2.4 GHz Intel Atom RAM: 4 GB - DDR3 Hard Drive: 64 GB (SSD of some sort - poss USB) Checking the read speed of the boot partition: $ sudo hdparm -tT /dev/mmcblk0 /dev/mmcblk0: Timing cached reads:

Re: Proposal: new fsfs.conf properties

Philip, > I don't believe Apache/mod_dav_svn uses TMPDIR when processing a PUT. > I can prove that either Apache or ModDavSvn (or the OS) uses TMPDIR during a PUT of a very large resource. Test 1: leave 3GB free on system drive, try to PUT 15GB file thru DAV into it's ultimate destination on a

Re: Proposal: new fsfs.conf properties

Well anecdotally, it wasn't oscillating like that in earlier phases. I'll do p4 obliterate and start over. I mean svn obliterate. Err :-P > > In fact it might be. A full filesystem may have a harder time finding > contiguous empty space, which may translate to more separate > (non-contiguous)

Re: Proposal: new fsfs.conf properties

Corveleyn <jcor...@gmail.com> wrote: > On Fri, Jul 14, 2017 at 1:18 PM, Evgeny Kotkov > <evgeny.kot...@visualsvn.com> wrote: > > Paul Hammant <p...@hammant.org> writes: > > > >> 1. compression-exempt-suffixes = mp3,mp4,jpeg > >>

Re: Proposal: new fsfs.conf properties

On Thu, Jul 13, 2017 at 06:34:17AM -0400, Paul Hammant wrote: > >> Or am I really wanting Svn's backend compression and deltification to be > >> out of band ? > >> > >> 1. compression-strategy = defer-to-idle-time-even-if-days-later > >> 2. de

Re: Proposal: new fsfs.conf properties

Sweet - I'll operationalize that ASAP. The client side of the sync agent knows whether the item is new or to be changed, already. - Paul > > > Sorry I'm gunna be a bit slow here, Philip, but you're saying that > sequence > > of four is a single atomic commit in Subversion? > > Yes. > >

Re: Proposal: new fsfs.conf properties

wrote: > On 13.07.2017 13:07, Paul Hammant wrote: > > > > > > The delete+recreate takes the same 5.2s as the original create and is > > faster than curl's 6.7s update. > > > > > > New fsfs config prop ? > > > > delete_and_recreate_in

Re: Proposal: new fsfs.conf properties

Sorry I'm gunna be a bit slow here, Philip, but you're saying that sequence of four is a single atomic commit in Subversion? - Paul On Thu, Jul 13, 2017 at 7:48 AM, Philip Martin wrote: > Philip Martin writes: > > > The fact that the create

Re: Proposal: new fsfs.conf properties

> > > The delete+recreate takes the same 5.2s as the original create and is > faster than curl's 6.7s update. > > New fsfs config prop ? delete_and_recreate_instead_of_change_threshold = 50MB -ph

Re: Big files PUT into Subversion - encountering

Markus - you may be right on hopes for perf improvements. I'm reevaluating what I said a couple of days ago in this thread. The best case PUT times for that 15GB random resource at *7 mins*, but about 1/5 of them are at *15 mins*. I'm going to try to undo the TMPDIR change and see if it goes back

Re: Proposal: new fsfs.conf properties

> > > > Mmm ... interesting proposition. Also huge -1 because it'd be a really > awesome abstraction leak. :) > Is there any way to implement the (reasonable in my opinion) feature request, without transgressing on programming standards? I think turning off all deltification is a bit brute

Re: Proposal: new fsfs.conf properties

On rationale ... This is a file sync agent. 600 lines of Python that I'm going to open source. The same thing I was working on in 2016 when I chatting on this list. Goals: 1) *not have two copies of everything on the clien*t, 2) have different semantics to pushing back changed files. Secondary

Re: Proposal: new fsfs.conf properties

Jul 12, 2017 at 10:40 PM, Paul Hammant <p...@hammant.org> wrote: > > I'd be fine with that too if it is also settable via curl --header > > "svn:compression: no" for non-client auto-increment operations. > > I'm wondering whether you'll still need this. You ended

Re: Proposal: new fsfs.conf properties

I'd be fine with that too if it is *also* settable via curl --header "svn:compression: no" for non-client auto-increment operations. On Wed, Jul 12, 2017 at 4:10 PM, Mark Phippard wrote: > I cannot find it in archives so maybe this happened in IRC, but I remember > one time

Re: Proposal: new fsfs.conf properties

You know, in all seriousness I think the (empty by default) list of exempted files suffixes the the best way forward. If suffixes is good enough for Apache itself to use (link provided earlier), it is good enough in this scenario on the server side of Svn. If the function in question doesn't know

Re: Big files PUT into Subversion - encountering

Reporting back - The /etc/apache2/envvars file is the *perfect* place to change the temp folder that Apache uses on load, and avoid an out of space error for bg files(see log above). I thought there might also be a speed boost for having the temp folder set to the same driver as the

Re: Proposal: new fsfs.conf properties

So I'm after a time saving. I'm perfectly happy for the backend to waste space (in my configuration), I just don't want it to take 15 mins to transfer a single 15GB file into Subversion. In my configuration, I'd like to pre-advise Subversion to save as much time as possible for uploads, by

Re: Proposal: new fsfs.conf properties

I'm perfectly happy for the solution to be mime-type based. Maybe we can take the mime-type to *suffix table* from Apache itself to do the translation :- https://svn.apache.org/repos/asf/httpd/httpd/trunk/ docs/conf/mime.types :-P I used it (implicitly) in a Subversion backed wysi-wiki *ten

Re: Proposal: new fsfs.conf properties

com> wrote: > Hi, > > (Sorry, it seems my previous message was sent _very_ prematurely :-( > > From: Pavel Lyalyakin [mailto:pavel.lyalya...@visualsvn.com] > > Hello Paul, > > > > On Sat, Jul 8, 2017 at 2:51 AM, Paul Hammant <p...@hammant.org> wrote: > &g

Re: Big files PUT into Subversion - encountering

I think I have tracked it to root cause: boot partition didn't have 10GB free at the time of the upload. There's a /etc/apache2/envvars file where I can change the location of TMP, I think. Which mean would mean that somewhere in the chain of Apache and it's modules the file system is used for the

Re: Big files PUT into Subversion - encountering

Interesting - the first restart of that sequence failed again for the same reason. I didn't try it a third time, I just rebooted the box (instead of apachectl restart), so I don't know if that was a *persistent* state for the implicit Svn server or not. On Sat, Jul 8, 2017 at 9:36 AM, Paul

Big files PUT into Subversion - encountering

Same system as before - 4GB RAM Intel Atom Linux box , with attached 4TB USB3 driver (yes in a USB3 port) where the svn repo's root is. AutoIncrement is turned on (or whatever it's called), and

Proposal: new fsfs.conf properties

1. compression-exempt-suffixes = mp3,mp4,jpeg 2. deltification-exempt-suffixes = mp3,mp4,jpeg Regardless of the setting of 'compression-level', #1 above two mean certain things can skip the compression attempt. It must give up at a certain point right? Same for deltification re #2 I'm

Re: Expected speed of commit over HTTP?

mistake. What I'm using is in fact: dd if=/dev/zero bs=1M count=500 2>/dev/null | openssl enc -rc4-40 -pass pass:weak > six - Paul On Fri, Jul 7, 2017 at 2:39 PM, Stefan Fuhrmann <stefanfuhrm...@alice-dsl.de > wrote: > On 07.07.2017 01:10, Paul Hammant wrote: > >

Re: Expected speed of commit over HTTP?

With autorevision set to 'on' and curl: Reverence speed for boot drive to USB3 spinning platter 4TB thing: paul@paul-HiBox:~$ time cp /home/paul/clientDir/seven /media/paul/sg4t/sevenb real 0m1.539s Create a new 501MB file on Svn Server: paul@paul-HiBox:~$ time curl -u paul:myPassword

Re: Expected speed of commit over HTTP?

e on the end server of any > size. HTTP/mod_dav and RTT is usually the culprit in our cases, on a LAN > that issues collapses. Likely server side processing of the delta's? > > -jacek > > On Thu, Jul 6, 2017 at 1:54 PM, Paul Hammant <p...@hammant.org> wrote: > >> For

Re: Expected speed of commit over HTTP?

Jul 6, 2017 at 8:03 AM, Branko Čibej <br...@apache.org> wrote: > On 06.07.2017 13:54, Paul Hammant wrote: > > For something that's 500MB in size (random binary data) I'm > > experiencing commits taking > > 10x longer than a straight copy to the drive the Svn

Expected speed of commit over HTTP?

For something that's 500MB in size (random binary data) I'm experiencing commits taking 10x longer than a straight copy to the drive the Svn repo is on. Both timings are on the same Ubuntu 17.04 machine, with the boot drive being the starting position of the 512MB file and a USB3 mounted 4TB

Re: [ANNOUNCE] Apache Subversion 1.9.6 released

Great work, all round :)

Re: [ANNOUNCE] Apache Subversion 1.9.6 released

Someone owns the consequential updates to Homebrew - right ? Ref: https://github.com/Homebrew/homebrew-core/blob/master/Formula/subversion.rb - Pull-Requests are the usual model, but there's easily room for duplicated effort, here. - Paul

Re: Progress on SHA-1 fixes in patch releases?

My apologies. When I wrote "No patch releases though, right?" my intention was to communicate "No patch releases YET though, right? -ph On Thu, Mar 30, 2017 at 6:28 AM, Branko Čibej <br...@apache.org> wrote: > On 30.03.2017 12:26, Paul Hammant wrote: > >>

Re: Progress on SHA-1 fixes in patch releases?

> Eh? Patch release changelogs get written when the patch is released. I'm not following what you're saying there.

Re: Progress on SHA-1 fixes in patch releases?

No patch releases though, right? http://svn.apache.org/repos/asf/subversion/trunk/CHANGES Is that because, "the server can store the offending PDFs" isn't enough of a releasable in its own right? Or because the "the server can store the offending PDFs" specifically is imperfect and

Re: Files with identical SHA1 breaks the repo

Why don't y'all take the same tactic as Git does - SHA1 the contents of the file *and a prepended a type/length field* ?. That and a tool to back convert SHA1s for existing repos. Linus weighed in again: https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL Svn is more likely to be used as a

Re: Files with identical SHA1 breaks the repo

Linus weighs on on Git's use of SHA1 (may be interesting) http://marc.info/?l=git=148787047422954=2

Re: Svn perf curiosity

to the same USB hard drive - different low-level libc calls to openssl? 2. I made a mistake about the built in SSD - it was fast regardless, despite previous advice. - Paul On Mon, Oct 31, 2016 at 8:27 AM, Paul Hammant <p...@hammant.org> wrote: > I'm curious as to what could make a checkin of

Re: New SHA1 property for nodes returned 'svn ls --xml' invocations.

With a maintained server-side merkle tree for repos/users y'all would be a little closer to the 'have set' fu of Perforce :) Sent from my iPhone > On Nov 1, 2016, at 6:29 AM, Julian Foad <julianf...@apache.org> wrote: > > Branko Čibej wrote: >> Paul Hammant wrote: >&

Re: New SHA1 property for nodes returned 'svn ls --xml' invocations.

van Zhakov <i...@visualsvn.com> wrote: > >> On 12 October 2016 at 14:03, Paul Hammant <p...@hammant.org> wrote: >> It's very exciting to hear that Subversion already calculates shas somewhere >> in the backend :) > I noted this multiple times on this thread: SHAs a

Svn perf curiosity

I'm curious as to what could make a checkin of a single 10MB file take 3 mins on a Linux machine, when it is 2 seconds on a Mac. I'm able to reproduce it easily: svnadmin create --fs-type fsx fsxRoot svn checkout file://$(pwd)/fsxRoot testLocalCheckout cd testLocalCheckout openssl

Re: New SHA1 property for nodes returned 'svn ls --xml' invocations.

You're right - and in the fullness of time, I'll replace all the Svn uses with their wire equivalents. If Shas were implemented at some future date, I'd be happy for them to be available via PROPFIND. I's be even more happy for them to be passed back to me in the response of a PUT. Or are you

Re: New SHA1 property for nodes returned 'svn ls --xml' invocations.

> > > As a test, I'm using openssl to make huge files that > > change wholly with every revision, and trying to find the top limits of > > Subversion. Sadly I've only found the top limits of Docker on the mac so > > far - 60GB. > > 60GB being the size of each revision of a single versioned file? >

Re: New SHA1 property for nodes returned 'svn ls --xml' invocations.

> > Thanks for these details, they clarify the picture. > :) > > I've read the ?kw=1 section of the release notes. My use case would not > > need keyword replacement. In fact it would need it to be off. > Are you sure? The only situations in which you'd need keywords > expansion *off* is if

Re: New SHA1 property for nodes returned 'svn ls --xml' invocations.

n 11.10.2016 14:09, Paul Hammant wrote: >> For the entry of directory that contains mod_dav_svn.c, I'd hope for the >> SHA1 to be a function of the SHA1s of the files within. That's Merkle-tree >> style - a super important feature generally as well as specifically to my >> use

Re: New SHA1 property for nodes returned 'svn ls --xml' invocations.

Merkle trees / hashes can help a server maintained graph of objects survive "Bitrot" (http://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/ - data in SSD or HD being corrupted by (say) nutrinos over time. See also a guy/gal lamenting their

Re: New SHA1 property for nodes returned 'svn ls --xml' invocations.

Replying to various. I'm making a Dropbox-a-like client that uses Svn/WebDav/AutoIncrement as the server. Critical design goal - to *not* have a classic Svn working tree locally. Think 50GB of binary files sync'd down to a client, and a wish to not have that take 100GB of local storage. > What

Re: New SHA1 property for nodes returned 'svn ls --xml' invocations.

com> wrote: On 24 September 2016 at 15:36, Paul Hammant <p...@hammant.org> wrote: > In order to be able to do some Merkle-tree style functions on sets of files > canonically held in Subversion, it would be great to ask Svn for a SHA1 for > the files, or collections thereof fro

Re: New SHA1 property for nodes returned 'svn ls --xml' invocations.

Isn't 'ls --xml' a machine interface? > > Using the Subversion API directly would be the best way to do this. The > checksum is available at the API level, but wouldn't serve any useful > purpose in the output of 'svn ls' -- which is, after all, a user, not > machine interface. > > -- Brane >

New SHA1 property for nodes returned 'svn ls --xml' invocations.

In order to be able to do some Merkle-tree style functions on sets of files canonically held in Subversion, it would be great to ask Svn for a SHA1 for the files, or collections thereof from that node downwards. I would raise a new feature request direct into Svn, but the JIRA notes says to not

Re: Svn capability for SparkleShare

My fork of sparkleshare now does svn-up and svn-commit well enough, in anyone is interested. It's only working on the svn:// protocol, and even then only for allow-anon-write repos. - Paul Sent from my iPhone > On Aug 25, 2016, at 6:18 PM, Paul Hammant <p...@hammant.org&

Svn capability for SparkleShare

SparkleShare: https://www.sparkleshare.org/ TL:DR: Like DropBox but your own SCM as the backing store, and not as-a-service. There's many non-DropBox host-it-yourself solutions, but none use a formal SCM as the backing store. So of course, SparkleShare is *super-stable for Git only*, but the

SVN-4635: Cherry-pick merge scenario causes Svn to choke

http://subversion.apache.org/docs/community-guide/issues.html amongst other things, says " if you're pretty sure about the bug, go ahead and post directly to our development list". OK, so here's a bug with merge tracking: https://issues.apache.org/jira/browse/SVN-4635 Synopsis: Series of

Subversion should merge with Mercurial (reverse takeover)

I've been nudged by nice people to post this here - honest !! 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.

<    1   2