Re: future of our "experimental" features

My bad. I misunderstood 'the "v1" implementation fails to shelve many kinds of WC modifications other than plain text changes' statement Julian made.

Re: future of our "experimental" features

I think y'all should promote something to mainstream, even if the performance isn't what you want it to be (for this feature). Better slow IMO, than "does the wrong thing". If y'all promote neither it'll just decay away from trunk and then risk never going live. As it doesn't affect any existing

Re: OpenBSD buildbot

Just change it to retries=5 on some fine-grained basis and stop worrying about it as long as that fixes it?

Re: Svn server images / appliances / packages

Here's one for AWS - https://aws.amazon.com/marketplace/pp/Bitnami-Subversion-Certified-by-Bitnami/B00NN8NOAE - but it does't meet your at home requirement. I've run several Svn's for various at home projects. Always into Ubuntu or Raspbian - following the setup scripts. Ten years back I put one

Re: GIT/Perforce like .svnignore

Of course.

Re: GIT/Perforce like .svnignore

All of which can be played out in the issues and the PRs of the most viable GitHub repo for this idea.

Re: GIT/Perforce like .svnignore

> ... "pointing at GitHub not going to solve anything" ... I was pointing at a GitHub repo in order for the OP to use that, and perhaps contribute to it there. It can easily be perfected there in (say) Python, and in a couple of years time re-implemened in C in for Svn on Apache's canonical Svn

Re: Re: GIT/Perforce like .svnignore

This is a fantastic feature. At least, it is very popular in Git and Mercurial. In lieu of the Svn dev team agreeing, there's at least two implementations on GitHub - https://github.com/search?q=subversion+ignore On Fri, Nov 29, 2019 at 11:12 AM Krzysztof Siewiorek wrote: > Hi, > Thank you all

Re: Python3 work [was: The run up to Subversion 1.13.0]

One more thing re Python3 - there's Svn Homebrew fu for Mac folks - https://github.com/Homebrew/homebrew-core/blob/master/Formula/subversion.rb - that work admirably for Python 2.7.x but has no code for Python 3. I don't think this brew formula is maintained in the svn dev team. Of course,

Re: What comes after 1.12?

My DevOps consulting life (around how to get to Trunk-Based Development from some often ClearCase inspired branching model), starts with what release cadence are you at now, and what do you want to get to. Clients who are quartly want to get to monthly (and have less unplanned releases following

Re: Subversion 2.0

The "shelve" functionality in Subversion may be grown into a "continuous review" system in the future. If you can't wait that long Rhodecode and Assembla both give Subversion a code review capability today and would be able to migrate your existing repo to their tech/service. Various CollabNet

Monorepos: Facebook's Mononoke and Eden (file system)

Monorepo tech: https://github.com/facebookexperimental/mononoke (Mercurial rewritten in Rust) File system: https://github.com/facebookexperimental/eden Xoogers (and friends) at Facebook toiling towards Google's in-house capability - formerly Perforce, since 2012 'Piper'. This -

Re: Subversion 2.0

> [..] How can we leverage Subversion's centralized structure to give > something _better_than modern workflows? I'm the guy behind http://trunkbaseddevelopment.com and am predictably going to say the workflow Svn needs to ace is trunk-based development. That includes (since 2008) some mechanism

Re: Subversion 2.0

> building those ideas on the Subversion 1.x code base +1 > Rust or Go +1. Rust doesn't yet target all the platforms that Subversion already targets. It will do though, there's something unstoppable about the Rust community. I commissioned Rust ports of Python pieces on UpWorks for fixed prices

Re: GitHub pull requests

The gaping hole in Subversion's capability, 11 years on from when GitHub launched with it, and 13 or so years from Google operational-izing the functional equivalent for themselves is patch-review in a way that each is re-creatable in working-copy by reviewers from the command line. GitHub made

Re: GitHub pull requests

> * include the patch (as an attachment?) in the PR mails https://coderwall.com/p/6aw72a/creating-patch-from-github-pull-request <- turns out GitHub has a secret URL that aids in that workflow. Remaining: a pledge for speedy processing of these. If standards for code donations are made clear,

Re: GitHub pull requests

One of the major GitHub social contributions to the community is the ease of forking. I don't mean as part of a "contribution workflow", but as a tool for getting an upstream team to change their attitude. A famous case was Node.js and how it ended well (merged again -

Re: Docker Svn build environment [was: Subversion's community health]

People wanting to donate a feature or fix a bug with Subversion are increasingly going to be happy with a Docker-based quick start. Most F/OSS teams want tests too, and y'all are very strict there in that regard, and someone who can write tests for your test-base covering code for your codebase is

Re: Subversion's community health

Dockerized build templates would be great for a quickstart. I might have one or two for Svn and if I de-hack them might be shareable. They'd be biased towards Linux for build/test/standup of course, but would be better than nothing.

Re: Subversion's community health

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 homebrew advice for people wanting to get into

Re: SvnMerkleizer: announcement

> 404 Not Found Yeah, my bad. Was a 'private' repo in GitHub, now public.

Re: Subversion's community health

Three PRs out on GitHub for Subversion spanning years - https://github.com/apache/subversion/pulls ^ "join in" versus "don't join" in is communicated via team welcoming, curating, and consuming of PRs in this age. Sure, Julian's shelve tech is the starting point of a PR system for Subversion

SvnMerkleizer: announcement

URL: https://github.com/paul-hammant/SvnMerkleizer It's a Java process that runs alongside Apache and MOD_DAV_SVN to make a full Merkle tree of the repo. Implicitly too, any sub-directory within. It attempts to maintain different trees for people with different read permissions/groups. Coming

Re: SHA1 collisions became cheaper to create.

Why a merkle tree? One of Subversion's strengths is its linear revision history. You could use blockchain and get financial strength audit ability. Blockchain is so over sold. There's a whole class of application where the bastard child of Git and Subversion would be a perfect non-repudiable and

Re: SHA1 collisions became cheaper to create.

The Git folks moved to a hardened SHA1 function as an interim measure on the way to SHA-256 - https://github.com/git/git/blob/master/Documentation/technical/hash-function-transition.txt I think you're generally right. While I might think that an auditor would simply be advised of the root hash

Re: SHA1 collisions became cheaper to create.

Yes, Subversion would remain good a keeping versions of honest development work. Problem I'm trying to solve: In an audit situation where prior commits were to be analyzed the owner of the repo that was motivated enough could tell the auditor that black was while in respect of a certain

Re: SHA1 collisions became cheaper to create.

I'm suggesting phasing out SHA1, and during a v1.x to v1.x+1 upgrade do a migration script for all content to gain (say) BLAKE2 hashes *instead*, and for that install, client's with incompatible hashing are rejected. There are alternates too, where up to a moment in time a repo has SHA1s, and

SHA1 collisions became cheaper to create.

Article: https://www.zdnet.com/article/sha-1-collision-attacks-are-now-actually-practical-and-a-looming-danger/ Subversion makes a SHA1 hash for each resource held. It is certainly available as part of the detail for a file/resource, but I don't know to what extend the PUT logic relies on it.

Re: [ANNOUNCE] Apache Subversion 1.12.0 released

The last note on 'shelve' is in 1.10 and that was to suggest it is experimental. Is that still the case in 1.12, or should it graduate to a different adjective now?

Re: Spack - package manager for Linux+Mac

In praise of that community, they appear to be "on it" with respect to problem reports - https://github.com/spack/spack/pull/10335 being an example that coming from an issue I'd had with their Python as I ran through the 1.9.7 install of Subversion with it. That after them quickly solving an

Spack - package manager for Linux+Mac

Spack currently has 1.9.7 as the most recent Svn that it can deliver: https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/subversion/package.py Someone may be interested in dipping their toe into that world and updating their script for them. - Paul

Re: Common header(s) for C and C++ API

My bad - I assumed the contents of #1850344 were all new, but of course the tests pre-existed that commit.

Re: Common header(s) for C and C++ API

http://svn.apache.org/viewvc?view=revision=1850344 ^ Any chance of example code being checked in too? Short how-to-embed-subversion for C++ and C, I mean. Others elsewhere could go on to do examples for Rust, Python, Java (https://github.com/bytedeco/javacpp), etc.

Re: How to join in to dev@

Hi Nathan, Some Apache mail lists won't like HTML email or "top-posting". I think the subversion dev mail list is one of those, but I could be wrong. You subscribe by emailing dev-subscr...@subversion.apache.org :) On GitHub Pull-Requests - yes that'd be super useful. Julian has been developing

Re: Suggestion: linkify revnums and issues in the CHANGES file

Markdown seems ubiquitous nowadays. In its raw form it is human readable, as well as being machine-parsable into HTML / PDF, etc. Git's README is markdown (https://github.com/git/git/blob/master/README.md) but the releases notes are still plain text (

Re: Shelving / Checkpointing thoughts

[going back in time to August 29th] > Apache products aren't allowed to depend on GPL'd code for mandatory / > core features. > > This is academic now as Julian is making great progress with his shelve tech that's built in to Subversion and idiomatic, but there are MIT licensed versions of Git:

Re: Subversion clients following HTTP 302 response codes.

Re https://issues.apache.org/jira/browse/SVN-4738 If I paid for this to be developed (say on UpWork), what criteria would that work have to meet to be consumed into Subversion's trunk for later release? I ask because I'd not want to pay for its development then have it rejected for a long list

Re: Subversion clients following HTTP 302 response codes.

My bad - I pasted/typed into the env field rather than the desc one. Fixed.

Re: Subversion clients following HTTP 302 response codes.

https://issues.apache.org/jira/browse/SVN-4738 filed :)

Re: Subversion clients following HTTP 302 response codes.

> I'm still wondering what you're aiming for though. An obvious example > would be offloading resource content storage from the repository server > to some other storage. But if you want to do that, relying on redirects > is hardly a good option, since you'd be increasing the number of > requests

Re: Subversion clients following HTTP 302 response codes.

The main conversation - PROPFIND, OPTIONS etc with a canonical centralized server, *but* select GETs (among many) being redirected to other URLs. My testing didn't show that that was supported. As a good XPer, I should be able to conjure up a script to show that but I can't, so I mean manual

Subversion clients following HTTP 302 response codes.

It would be cool if svn.exe (the client) could follow HTTP return code '302' during svn-co and svn-up operations. I'm thinking that this is just for GET* of resources, and that someone who's managed to *front* their Mod_Dav_Svn with something that can do redirects for select resources. Say to

Re: Potential regression: high server-side memory consumption during import

> Yes, the problem seems to be that mod_authz_svn has no way of storing per-connection state at present. Please excuse the interjection here: My eyes spied "per connection" and I wondered if something I'm doing elsewhere that is closer (but not exactly) "per user" might help in terms of thinking.

Re: Building Subversion on Debian stretch with serf support

> I'll have an updated Debian package uploaded to experimental in the next few days. Which will be great, Philip. I look forward to it :) And thanks for the `apt-get build-dep subversion` tip off.

Re: apt-get installs for the Svn build on Raspbian 'Stretch' (Nov, 2017)

Another SD card, another permutation to get the basic build working for Subversion: apt-get install apache2-dev libsqlite3-dev libserf-dev liblz4-dev libutf8proc-dev sqlite3 subversion libapache2-mod-svn This is getting quite easy now :) Someone should make a webapp that translates rpm,

Subversion build ... but just client commands?

I'm probably never going to deploy a Svn server on the Mac or Windows10(S) - keep up the good work Satya! What are the options for ./configure and make to focus on the client executables only, and skip svnserve and mod_dav_svn? - Paul

Re: Building Subversion on the Mac

The homebrew install does a source compile rather than pluck of a binary and compare to a SHA256 ? -Paul

Re: Building Subversion on the Mac

This seems to work for me, based on your advice: ./configure --with-apr=/usr/local/opt/apr --with-apr-util=/usr/local/opt/apr-util --with-apxs=/usr/local/opt/apache2/bin/apxs I'm thinking those are solid Homebrew paths for most people.

Building Subversion on the Mac

Based on Brane's email from yesterday, I did a build for Subversion on the Mac, with Homebrew and XCode installed already. brew install apr apr-util httpd serf zlib berkeley-db swig lz4 utf8proc # These two were necessary for me, for some reason # Although handing flags to ./configure was an

apt-get installs for the Svn build on Raspbian 'Stretch' (Nov, 2017)

On that Pi3 again - the joy of having many microSD Cards :) apt-get install apache2-devel apt-get install libsqlite3-dev apt-get install libserf-dev apt-get install liblz4-dev apt-get install libutf8proc-dev apt-get install sqlite3 Everything else was installed already. Installation goes to

Subversion openSUSE build pre-requisites

OpenSUSE is interesting to me because it has a 64bit image for the RspberryPi3 , and there is no 64 bit version of Raspbian, presently. If anyone is interested, the 1.10 branch (if not more) builds on the Pi3 after these additional package installs:

Re: Tree conflict 'svn merge' message

Here's one from the past - https://issues.apache.org/jira/browse/SVN-3495 - A famous airline was the client back then and they were strangling their older (but accomplished) cgi-bin/C++ stack. We were doing concurrent development of consecutive releases. Different teams from two consultancies

Feature suggestion: determination of the subversion commit number for a directory (over DAV without svn clients involved)

to get the revision numbers for directories - see here: https://github.com/paul-hammant/SvnMerkleizer/blob/master/src/main/java/com/paulhammant/svnmerkleizer/App.java#L330 (method get getSvnRevision). Can the XML response of PROPFIND be enhanced to have an extra element that reports the revision

Re: Authz suggestion

Filed - https://issues.apache.org/jira/browse/SVN-4710

Re: Authz suggestion

Jira feature request needed to capture anything from this thread? Maybe not, if plans were already in action anyway...

Re: Authz suggestion

> > > Specifically, by "currently" I mean that this is the state on trunk. :) > I don't believe anyone is working on adding explicit traversal > permission on trunk in time for 1.10. It would require some rework of > the way the authz info is used within the core libraries, it's not just > a

Re: Authz suggestion

> Currently it's implied in 'r' and 'rw' modes. Great news. Specifically by currently you mean in 1.9.7 right? And that further enhancements are Coming in 1.10. You also said you’ve a plan for further enhancements :)

Authz suggestion

Consider: [/] harry=rw [dataset:/A] sally=rw [dataset:/Z] sally=rw If I had directories B through Y, I am pretty sure Sally cannot see them let along change anything in them. Cool that's what I want. What I don't have though is the ability for Sally to checkout from root and recieve A/* and

Re: Authz - paths with trailing slash isn't supported - right?

> > > > Should I raise this in https://issues.apache.org/jira/browse/SVN > > or not ? > > We could clarify the error message by having it refer the admin to the > server log. We might also have the error message state "The authz file > failed to parse" (without details; we'd consider the authz

Re: Authz - paths with trailing slash isn't supported - right?

> > The cause of the 403 should be logged on the server side. >> > > It was: > > [Sat Dec 09 22:24:47.803767 2017] [authz_svn:error] [pid 13] [client > 172.17.0.1:35066] Failed to load the mod_authz_svn config: Section name > '/foo/a/' contains non-canonical fspath '/foo/a/' > [Sat Dec 09

Re: Authz - paths with trailing slash isn't supported - right?

> > > No, it's intentional: > > https://subversion.apache.org/docs/release-notes/1.8.html# > authz-fspath-syntax > > The cause of the 403 should be logged on the server side. > It was: [Sat Dec 09 22:24:47.803767 2017] [authz_svn:error] [pid 13] [client 172.17.0.1:35066] Failed to load the

Re: Authz - paths with trailing slash isn't supported - right?

> > > The / on the root is not a trailing slash; it's a leading slash. Paths > in the authz file must /start/ with a slash. > Obvious really, I guess.

Authz - paths with trailing slash isn't supported - right?

In authz files, [/] is often mentioned as a cross-cutting repo root that has permissions for users and groups. There's no other references to a path in square brackets with a trailing slash. At least, not in http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html. That was

A server-side merkle-tree capability for ordinary Subversion* installs.

Implementation here - https://github.com/paul-hammant/SvnMerkleizer. It is written In Java in about 600 lines of code. There's unit and integration tests too (coverage between those two is 92%). In operation it is pretty slow to build caches, but performs really well after that when there's

Re: Ideas for tracking Authz changes in a repo

s/Marc/Mark/ sorry ... I've been dealing with a fellow with the other spelling today in work.

Re: Ideas for tracking Authz changes in a repo

Thanks for this Marc. I'll go ahead and play with it to learn it capabilities and (hopefully few) snags. - Paul

Ideas for tracking Authz changes in a repo

One thing I need to be able to do in the near term is track when authz settings change for a user (or groups). It'd be great if Svn had the authz file (optionally) under source control. I'd be happy with 1) a robot user performs a *copy* of the file from its canonical location and automatic

Re: Augmenting the WebDAV side of Subversion with merkle hashes for directories.

OK, not a straight handler, but 'ScriptAliasMatch'. Like so: ScriptAliasMatch \.foo*$ "/path/to/helloworld.py$1" I should be able to hit /a/b/d/e/f.foo in a browser and have helloworld.py execute, right? Well, it works just fine when declared at root level (not in a or directive) and for

Re: Augmenting the WebDAV side of Subversion with merkle hashes for directories.

Well the code from that blog entry works as reported for declarations but not for ones where mod_dav_svn is the handler. I recreate both of those in a single server implementation if I mount the a svn/ folder inside the canonical docroot (as is common), then play with URLs that should be

Re: Subversion 1.10 RC1?

t; wrote: > On Thu, Nov 23, 2017 at 03:53:02PM -0500, Paul Hammant wrote: > > > > > > > > > > Is that a regression versus v1.9 and before? > > > > > > Far from it. > > > This discussion is about the new conflict resovler added in 1.10.

Re: Augmenting the WebDAV side of Subversion with merkle hashes for directories.

Yup. I'm able to go down a rabbit hole on things, though. I've just spent an hour trying to find a docker image to start with so that I was able to ship something that's easily run as an an example for this group. Who knew there's a *few thousand* ways of configuring Apache in docker images, heh?

Re: Subversion 1.10 RC1?

> > > > Is that a regression versus v1.9 and before? > > Far from it. > This discussion is about the new conflict resovler added in 1.10. > > We can and always could perform such merges by manually specifying > the paths, i.e. running a merge from ^/trunk/B to branch/A. > > The goal of the

Re: Augmenting the WebDAV side of Subversion with merkle hashes for directories.

"Two docroots" might be what I'm looking for: http://madbean.com/2007/two- docroots/ The author, Matt Quail, has been Jira lead for a decade, I think.

Augmenting the WebDAV side of Subversion with merkle hashes for directories.

OK, so most of ye know I am on this quest. *Context*: I've a working merkle-ish client tracking changes in a Svn server over DAV, and noting when files directories change and replicating that change on the client side. For files it gets the SHA1 for the file, stores it, and updates local file

Re: Subversion 1.10 RC1?

> > > One conflict option that's not done yet is one that merges a textual change > from a path ^/trunk/B to a path ^/branch/A, after a move A -> B on trunk. > I don't consider this a release blocker. We can always add this option in > a patch release. > > Is that a regression versus v1.9 and

Re: Checkpointing v1 design -- terminology

> > $ svn save --revert -v2 "add hair color to person page" >> >> .. does the save and THEN drops the CL and it's changes in working copy - >> back to no changes but not necessarily up to date. >> > > That sounds like you're proposing an alternative syntax for what the > 'shelve' command does --

Re: Checkpointing v1 design -- terminology

I'd be happier with save-cl rather than ci-save. Or just 'save', as I'm not sure what you're saving if not a change list. Incidentally CL looks pretty close to CI in lower case and that's already used. Spaces allowed in FOO name? $ svn save -v2 "add hair color to person page" Also.. $ svn

Re: Subversion Design Contribution Question

I'm also interested in standardized server-side handling of such things for a different reason to the one you state - code reviews. Well outside the purview of vanilla Subversion for sure, but a feature that the portal vendors have or are coding themselves. I've a love of Trunk-Based Development

Re: Building Subversion on the Mac

> > I sent you my build script for the Mac, that uses Homebrew, a while ago. > Why are you still having problems? > > You're right, you did. I'll take another look, Brane. Meanwhile I wrote: https://github.com/subsyncit/subsyncit/wiki/Building-Subversion-on-the-Mac

Contributing to the "how to build" documentation

There's a file tools/dev/unix-build/README that has some information. Is it up to date? It's not referred to in other files. Most importantly, not in/from /README. - Paul

Re: Building Subversion on the Mac

Yup, that builds through to completion, now. Thanks Troy.

Re: Building Subversion on the Mac

Yup, glibtool is needed on the Mac (brew install libtool makes /usr/local/bin/glibtool). That and a corresponding shim source: #!/bin/sh /usr/local/bin/glibtool "$@"

Re: Building Subversion on the Mac

to /bin/sh to execute. This feels like a wrapper-like thing, and I've googled a little, but can't see anything clear like "copy this script to folder/libtool". - Paul On Sat, Oct 28, 2017 at 8:07 AM, Troy Curtis Jr <troycurti...@gmail.com> wrote: > > > On Sat, Oc

Building Subversion on the Mac

OK, so I can get so far ... svn co http://svn.apache.org/repos/asf/subversion/trunk subversion cd subversion brew install libtool apr cp /usr/local/Cellar/libtool/2.4.6_1/share/libtool/build-aux/config.sub build/ autoconf ./configure --build=x86_64 --prefix=/usr/local --with-openssl --with-ssl

Subsyncit - file sync that uses Subversion as a backend.

http://subsyncit.com/ If you're prepared to make a few additions to httpd.conf you get running with this Python3 technology to do file-sync using Subversion as the backing store. It doesn't require any client side Subversion install, but does Python and some pips. At least up until I make an

Re: How to manage PR's (was: [GitHub] subversion pull request #6: VC should be 14.1 and not 15.0)

xpect patch submissions on dev@ instead)? > > If you ask people comfortable with donating code via PR to email patches (or similar) to dev@ instead, you'll get a 1/100th contribution rate. Or worse. There's no easy answer. Partially related - I'd previously whined about GitHub's lock-in for some dat

Re: MKCOL question

Well pipelining into Svn's HTTP 1.1 interface does work as you suggested. There is a library in Python called 'hyper' that does it - http://hyper.readthedocs.io/en/latest/quickstart.html#streams though the example get_response signature is not current (I raised a bug). Also, if I change

Re: Merkle trees in svn [was: Quick question about the sha1-checksum for directories in svn.]

Yikes! I'll have to run through the build setup for Subversion - 52 pages of requirements *before* launching ./config, right? - including wind-of-newt, left handed screwdriver, *two* four-leaf clovers ;) :-P Seriously: sounds good - and I appreciate it :)

Re: Merkle trees in svn [was: Quick question about the sha1-checksum for directories in svn.]

As my forthcoming multi-user app that uses Subversion as a backing store is going to kill Svn it with Depth-∞ PROPFINDs from root, I really want to see this implemented. Because I can't wait I will implement something that calculates SHA1s for the directory in question, and drops it into a

MKCOL question

Hi gang, *(non subversion-client usage warning, also BDD ahead warning)* Given I have a directory /path/to/missing/directory/ that does not exist on the Svn server at all When I want to put a file in there (say foo.mp3) Then I have to MKCOL path/ And I have to MKCOL path/to/ And I have to MKCOL

Re: Merkle trees in svn [was: Quick question about the sha1-checksum for directories in svn.]

Agree. For those that are super interested in this, I did a series of four blog entries on Merkle trees and Blockchains. - Sept 28th » Choosing Between Blockchains And Vanilla Merkle Trees -

Re: Merkle trees in svn [was: Quick question about the sha1-checksum for directories in svn.]

> "Obeying read permissions" means that the directory hashes would have to > be computed dynamically for each user. Yes I know. I've a frankenstein project over here - https://github.com/paul-hammant/merkle-rust - There's a solid Rust merkle tree that watches for changes at nod

Re: Merkle trees in svn [was: Quick question about the sha1-checksum for directories in svn.]

Not that my vote counts for much, but I'd prefer w/o props, obeying read permissions.

Re: Quick question about the sha1-checksum for directories in svn.

> Correct. Thanks Julian. Observation: If it did then Subversion would qualify as a *full* Merkle tree implementation. Albeit through APIs designed for other purposes :-p ;)

Quick question about the sha1-checksum for directories in svn.

While a _directory_ has a revision number, it does not have a SHA1 does it? If so there's no point asking how it's calculated, is there ? - Paul

Re: Sparse checkouts suggestion

> > > I'm not sure if you agree or not, but I think the fine-grained globbing > include/exclude capability as Perforce has it. is required. > > > "Required" implies "working copy format change". That's always hard. > > "Optional" means "get some of the features sooner." > I'm a big advocate for

Re: Sparse checkouts suggestion

> > > > 2. Previously I forked a medium-sized Monorepo on Github, and did the the > complete expand/contract work for it - https://github.com/paul-hamm > ant-fork/jooby-monorepo-experiment - in Python. > > LOGIBALL's Tim Krüger has just written about a deployment of an expanding/contracting

Re: Sparse checkouts suggestion

> > [...] > > if /foo does not exist at checkout time -- and if we'd want /* to mean > "include anything new that appears in the repository", not "include > everything else that's in the repository at the time of the checkout". > I'm not sure if you agree or not, but I think the fine-grained

Re: Sparse checkouts suggestion

> On 19.09.2017 00:59, Paul Hammant wrote: > > I like the `svn co svn://vcs/trunk --view foo`. Well maybe if in a > > following `svn up` it would *remember the current view*, it would be > good. > > > I don't think there's any need to remember the "current view&q

Re: Sparse checkouts suggestion

I like the `svn co svn://vcs/trunk --view foo`. Well maybe if in a following `svn up` it would *remember the current view*, it would be good. > I'm not sure about listing the "available views" in a default > property, but okay, it's a possibility. I think it would be nice to be > able to read it

  1   2   >