Re: svn commit: r1803143 - in /subversion/trunk/subversion: include/ libsvn_delta/ libsvn_ra_serf/ mod_dav_svn/
Good morning Evgeny,
kot...@apache.org wrote on Thu, 27 Jul 2017 09:00 +:
> +++ subversion/trunk/subversion/include/svn_delta.h Thu Jul 27 09:00:43 2017
> @@ -678,6 +690,9 @@ svn_txdelta_skip_svndiff_window(apr_file
> * @{
> */
>
> +/* Forward declarations. */
> +typedef struct svn_delta_editor_t svn_delta_editor_t;
> +
> /** A structure full of callback functions the delta source will invoke
> * as it produces the delta.
> *
> @@ -859,7 +874,7 @@ svn_txdelta_skip_svndiff_window(apr_file
> * dead; the only further operation which may be called on the editor
> * is @c abort_edit.
> */
> -typedef struct svn_delta_editor_t
> +struct svn_delta_editor_t
> {
>/** Set the target revision for this edit to @a target_revision. This
> * call, if used, should precede all other editor calls.
> @@ -1131,9 +1146,38 @@ typedef struct svn_delta_editor_t
>svn_error_t *(*abort_edit)(void *edit_baton,
> apr_pool_t *scratch_pool);
>
> + /** Apply a text delta stream, yielding the new revision of a file.
> + *
> + * @a file_baton indicates the file we're creating or updating, and the
> + * ancestor file on which it is based; it is the baton set by some
> + * prior @c add_file or @c open_file callback.
> + *
> + * @a open_func is a function that opens a #svn_txdelta_stream_t object.
> + * @a open_baton is provided by the caller.
> + *
> + * @a base_checksum is the hex MD5 digest for the base text against
> + * which the delta is being applied; it is ignored if NULL, and may
> + * be ignored even if not NULL. If it is not ignored, it must match
What's the rationale for allowing drivees to ignore the checksum?
This leeway enables failure modes that wouldn't be possible without it.
(Drivers that are aware of this leeway will validate checksums even if the
drivee doesn't, leading to duplicate work; drivers that are unaware of this
requirement might not get checksum errors they should have.)
I get that you just copied this part of the docstring from apply_textdelta(),
but I'd like to understand what's the rationale here. (And to see if this
leeway should be deprecated)
> + * the checksum of the base text against which svndiff data is being
> + * applied; if it does not, @c apply_textdelta_stream call which detects
> + * the mismatch will return the error SVN_ERR_CHECKSUM_MISMATCH
> + * (if there is no base text, there may still be an error if
> + * @a base_checksum is neither NULL nor the hex MD5 checksum of the
> + * empty string).
To the best of my knowledge, we don't special case the empty string's checksum,
d41d8cd98f00b204e9800998ecf8427e, anywhere. We do special-case
, though. I assume the parenthetical should be
fixed accordingly (both here and in apply_textdelta())?
> + *
> + * Any temporary allocations may be performed in @a scratch_pool.
Need to add an @since tag here.
> + */
> + svn_error_t *(*apply_textdelta_stream)(
Could you update the docstring of svn_delta_editor_t itself to mention this new
callback? All other callbacks are discussed there.
>
Is adding this function an ABI-compatible change? The docstring of
svn_delta_editor_t does say """
* @note Don't try to allocate one of these yourself. Instead, always
* use svn_delta_default_editor() or some other constructor, to ensure
* that unused slots are filled in with no-op functions.
""", but an API consumer might have interpreted this note as meaning "You may
use malloc(..., sizeof(svn_delta_editor_t)) if you take care to initialize all
struct members", in which case, his code will not be ABI compatible with 1.10.
> +const svn_delta_editor_t *editor,
This parameter is undocumented.
Cheers,
Daniel
> +void *file_baton,
> +const char *base_checksum,
> +svn_txdelta_stream_open_func_t open_func,
> +void *open_baton,
> +apr_pool_t *scratch_pool);
> +
>/* Be sure to update svn_delta_get_cancellation_editor() and
> * svn_delta_default_editor() if you add a new callback here. */
> -} svn_delta_editor_t;
> +};
>
>
> /** Return a default delta editor template, allocated in @a pool.
>
Re: [GitHub] subversion pull request #4: TEST: creating a new file
I'm trying to find out how much the apache/subversion repo on GitHub is integrated with ASF infrastructure. I filed a Jira ticket with ASF infra asking them about this, https://issues.apache.org/jira/browse/INFRA-14978 On 29/08/17 21:15, julianfoad wrote: > GitHub user julianfoad opened a pull request: > > https://github.com/apache/subversion/pull/4 > > TEST: creating a new file > > TEST: This is a test, to see if GH pull request is integrated with ASF. > > You can merge this pull request into a Git repository by running: > > $ git pull https://github.com/julianfoad/subversion patch-1 Huh, that doesn't look like something you can do on GitHub: it doesn't have a CLI/shell interface, does it? Instead, to merge this PR, I'd expect to press a button on the web page at https://github.com/apache/subversion/pull/4 but I don't see one. Presumably I don't have write access permission. How can I get it? Or is it because it is a read-only mirror? Anyone know where is the best place to read & discuss details of GitHub-ASF integration, not specifically for Subversion project but for ASF projects in general? Interested in knowing what's possible. - Julian
[GitHub] subversion pull request #4: TEST: creating a new file
GitHub user julianfoad opened a pull request: https://github.com/apache/subversion/pull/4 TEST: creating a new file TEST: This is a test, to see if GH pull request is integrated with ASF. You can merge this pull request into a Git repository by running: $ git pull https://github.com/julianfoad/subversion patch-1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/subversion/pull/4.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4 commit 7224ccc904231a4072ead9022f06444d23542a7f Author: Julian Foad Date: 2017-08-29T20:14:00Z TEST: creating a new file TEST: This is a test comment, to see if GH commenting is integrated with ASF mailing list. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: Tip of the day: Cheatsheet for common cmdline client operations
Hello, On Fri, Aug 25, 2017 at 2:03 PM, Johan Corveleyn wrote: > > [ cc -= svnbook-dev, as I guess this will not become 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 Jun 2017 09:15 +: > >> > I just ran into the following cheatsheet: > >> > > >> > http://www.chim.unifi.it/~signo/did/etc/subversion/neat.html > >> > > >> > It covers the normal multi-user workflow, branching, etc.. > >> > > >> > (Kudos to the author, Giorgio Signorini, not to me.) > >> > >> As some of you know, the author gave us permission to incorporate that > >> cheatsheet into the official documentation. Any volunteers to start the > >> process? > >> > >> Cheers, > >> > >> Daniel > >> > > 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. I'm > > happy to link to the cheatsheet from from the book website, though. > > > > -- Mike > > FWIW, I think this cheatsheet is quite good and valuable (though I > agree there is a lot of overlap with existing documentation), > especially for newcomers. Just to have a good summary / reminder of > common things you'll encounter. > > We have our own quickstart page: http://subversion.apache.org/quick-start > > How about: > > - Putting a link at the bottom of that page (there is already a link > to the quickstart section of the book), linking to the original > webpage of the author. > > or > > - Incorporating (some of) the content of that cheatsheet directly on > http://subversion.apache.org/quick-start, so it's right there in front > of you ... > > > The latter option would be my personal preference (putting my user / > admin hat on) -- I like having short info right in front of me in the > right place -- but obviously imposes some amount of doc-maintenance > work on "us". > > Maybe someone on this list would be willing to take this doc-task > (migrating the current content, and keep an eye on keeping it up to > date)? > > -- > Johan IMO, this doc-task has to be reworded into composing a walkthrough for SVN end user who wants to start performing basic version control tasks over remote repository, but did not read SVNBook or other SVN-related documentation. What do you think? I feel that the cheatsheet[1] needs to be reworked or at least restructured. In the current state I feel that it is just personal notes that describe various common SVN tasks, actions and tricks. Cheatsheet or personal notes is not a "quick start" guide. Anyway, I like the idea of adding some of the content from the cheatsheet to the quick start page[2] and I would be glad to take this task. The question is: what kind of topics should the quick start page cover? My idea is that the page should provide task-based guidance for SVN end user on how to * checkout a working copy, * update the working copy, * modify the data in the working copy and commit it, * make a branch or tag, * perform a simple merge. BTW, don't miss SVN-related docs on StackOverflow Documentation[3]. I'm pretty sure that some of the topics from that doc will be useful. [1]: http://www.chim.unifi.it/~signo/did/etc/subversion/neat.html [2]: http://subversion.apache.org/quick-start [3]: https://stackoverflow.com/documentation/svn/topics -- With best regards, Pavel Lyalyakin VisualSVN Team
Re: svn ls --search/pattern/glob/case-insensitive [was: svn commit: r1806548 ...]
On 29.08.2017 13:28, Stefan Sperling wrote: > On Tue, Aug 29, 2017 at 01:12:07PM +0200, Stefan Fuhrmann wrote: >> How would you implement the case-insensitive comparison >> on the server side consistent with the client-side locals? > As far as I can tell the utf8proc code which the client uses > for this is local-independent. "Locale," but yes. Utf8proc relies on the Unicode generic case-folding rules, which are indeed locale-independent. They won't always be 100% grammatically correct for a particular environment, but from my reading they'll be good enough for the purpose, which is to find stuff not write a linguistic thesis. A few strictly-speaking false-positive edge cases won't hurt. -- Brane
Re: svn ls --search/pattern/glob/case-insensitive [was: svn commit: r1806548 ...]
On Tue, Aug 29, 2017 at 01:12:07PM +0200, Stefan Fuhrmann wrote: > How would you implement the case-insensitive comparison > on the server side consistent with the client-side locals? As far as I can tell the utf8proc code which the client uses for this is local-independent.
Re: Towards a Shelving MVP
On 28.08.2017 22:41, Johan Corveleyn wrote: > I'm not an expert, but do you really need the modified file itself, if > you have the patch and a reference to the base file (pristine)? Why > store both F (pristine) and F' (modified file), if I can reconstruct > F' out of F + P (patch). You need source plus delta. We know how to create deltas, and they're more compact than patches. Only be aware that by then you're well down the path of re-creating repository functionality in the working copy. :) (Though, to be fair, that's exactly what's needed for shelving and checkpointing ... plus a few "tiny" extra features that the WC already has.) -- Brane
Re: svn ls --search/pattern/glob/case-insensitive [was: svn commit: r1806548 ...]
On 29.08.2017 12:46, Julian Foad wrote: Evgeny Kotkov wrote: Bert Huijben writes: As Julian discovered, '--search' as used with 'svn log' is may not suitable for 'svn ls'. File name matching should be case-sensitive and requires full patterns just like e.g. the ordinary unix command line 'ls' command. Therefore, introduce a separate '--pattern' option for 'svn log' that works similar to patterns with Unix command line 'ls'. Since the actual matching already confirms to that, we only need a different option pre-processing. Perhaps we could use --glob, to allow other syntax patterns later? Not sure... perhaps --glob is too technical. My 2 cents on this would be that having "svn ls --pattern" and "svn log --search" which only differ in terms of case sensitivity have a chance of being confusing for the users. I agree that's confusing, even just having two different option names is confusing. Perhaps, a slightly better way would be to keep the case-insensitive behavior by default, but add a "--case-sensitive" switch to handle the cases where it's required? That is, svn ls --search svn ls --search --case-sensitive I don't think a case-sensitive mode is necessary. Remember, this is a user interface. It is to help users find things. It does not attempt to be a programmatic search tool with all the precision and flexibility of Unix 'find -name -maxdepth -prune ...'. I expect almost zero use cases would require case-sensitive matching at this UI level, and that is why we made 'svn log --search' just be case-insensitive always. How would you implement the case-insensitive comparison on the server side consistent with the client-side locals? -- Stefan^2.
Re: 'svn list --search' feature complete?
On 29.08.2017 12:22, Johan Corveleyn wrote: On Tue, Aug 29, 2017 at 12:08 PM, Stefan Fuhrmann wrote: On 18.08.2017 13:36, Johan Corveleyn wrote: On Sun, Jan 29, 2017 at 10:35 AM, Stefan Fuhrmann wrote: On 24.01.2017 12:20, Stefan Sperling wrote: ... I would like to get an 1.10.0 alpha1 released in February. Unless I hear objections I will start rolling this alpha release from trunk and call a vote on it soon. Originally, I wanted to complete the get_list API before the alpha release but I can't make any commitments. So, it is probably better to roll the alpha with whatever is on /trunk at that time. -- Stefan^2. Hi Stefan2, Is the current state of the new get_list API complete on trunk now? Is the 'svn list --search' feature useable / good enough for beta? Context: on IRC we were talking about releasing a 1.10 beta, so this crossed my mind as one of the new features that might not be complete yet. BTW: 'svn list --search' isn't described in the release notes yet (and neither in CHANGES I believe). Sorry that had fallen off the edge of the disk for the last couple of weeks. Been super busy and then went fully off the grid for the last two weeks. r1806548 fixes the inconsistency that Julian found. Are you sure? As I understood from Julian's mail, the problem with the case-sensitivity really seemed like a bug: files with uppercase characters were simply not found, not even if the pattern was spelled out in uppercase. See the last one here below: $ svn list | grep -i "^co" COMMITTERS configure.ac contrib/ $ svn list --search 'co*' configure.ac contrib/ $ svn list --search 'CO*' configure.ac contrib/ So that looks like: you tried to make it case-insensitive (by converting the pattern to lowercase internally), but it doesn't work (because the paths are not converted similarly or something). (I haven't tested it myself) The thing is that --search "normalizes" the given patterns to lower-case and handles accents. --patterns only converts to UTF-8. Orthogonally: I think case-insensitive matching would be nice to have as well (either always, or optionally with some flag / pattern prefix / ...). Use case: Windows user base, trying to search for files with an extension, like *.PNG, *.png, ... Not sure that will work on the server-side. -- Stefan^2.
Re: svn commit: r1806552 - /subversion/branches/shelve/subversion/svn/svn.c
Bert Huijben wrote: > svn patch supports binary content. The limitation here is probably that > currently only 'svn diff --git' produces the patches in the proper form, > while other invocations skip binary files. Yes, this is noted right at the end of the design doc: https://docs.google.com/document/d/1PVgw0BdPF7v67oxIK7B_Yjmr3p28ojabP5N1PfZTsHk/edit#heading=h.4sj99cgksge9 Thanks for mentioning it. - Julian
svn ls --search/pattern/glob/case-insensitive [was: svn commit: r1806548 ...]
Evgeny Kotkov wrote: > Bert Huijben writes: >>> As Julian discovered, '--search' as used with 'svn log' is may not suitable >>> for 'svn ls'. File name matching should be case-sensitive and requires >>> full patterns just like e.g. the ordinary unix command line 'ls' command. >>> >>> Therefore, introduce a separate '--pattern' option for 'svn log' that works >>> similar to patterns with Unix command line 'ls'. Since the actual matching >>> already confirms to that, we only need a different option pre-processing. >> >> Perhaps we could use --glob, to allow other syntax patterns later? >> >> Not sure... perhaps --glob is too technical. > > My 2 cents on this would be that having "svn ls --pattern" and "svn log > --search" which only differ in terms of case sensitivity have a chance of > being confusing for the users. I agree that's confusing, even just having two different option names is confusing. > Perhaps, a slightly better way would be to keep the case-insensitive behavior > by default, but add a "--case-sensitive" switch to handle the cases where > it's required? > > That is, > > svn ls --search > > svn ls --search --case-sensitive I don't think a case-sensitive mode is necessary. Remember, this is a user interface. It is to help users find things. It does not attempt to be a programmatic search tool with all the precision and flexibility of Unix 'find -name -maxdepth -prune ...'. I expect almost zero use cases would require case-sensitive matching at this UI level, and that is why we made 'svn log --search' just be case-insensitive always. Simplicity and consistency are key. - Julian
RE: svn commit: r1806552 - /subversion/branches/shelve/subversion/svn/svn.c
> -Original Message-
> From: julianf...@apache.org [mailto:julianf...@apache.org]
> Sent: dinsdag 29 augustus 2017 12:25
> To: comm...@subversion.apache.org
> Subject: svn commit: r1806552 -
> /subversion/branches/shelve/subversion/svn/svn.c
>
> Author: julianfoad
> Date: Tue Aug 29 10:25:21 2017
> New Revision: 1806552
>
> URL: http://svn.apache.org/viewvc?rev=1806552&view=rev
> Log:
> On the 'shelve' branch: Expand & clarify help text; state limitations.
>
> * subversion/svn/svn.c
> (svn_cl__cmd_table): Tweak help text for shelve commands.
>
> Modified:
> subversion/branches/shelve/subversion/svn/svn.c
>
> Modified: subversion/branches/shelve/subversion/svn/svn.c
> URL:
> http://svn.apache.org/viewvc/subversion/branches/shelve/subversion/svn/
> svn.c?rev=1806552&r1=1806551&r2=1806552&view=diff
> ==
>
> --- subversion/branches/shelve/subversion/svn/svn.c (original)
> +++ subversion/branches/shelve/subversion/svn/svn.c Tue Aug 29 10:25:21
> 2017
> @@ -1650,23 +1650,31 @@ const svn_opt_subcommand_desc2_t svn_cl_
> {opt_targets, 'R', opt_depth, 'q', opt_changelist} },
>
>{ "shelve", svn_cl__shelve, {0}, N_
> -("Shelve changes.\n"
> +("Put a local change aside, as if putting it on a shelf.\n"
> "usage: 1. shelve [--keep-local] NAME PATH...\n"
> " 2. shelve --delete NAME\n"
> " 3. shelve --list\n"
> "\n"
> - " 1. Save the local changes in the given PATHs to a patch file, and\n"
> - " revert those changes from the WC unless '--keep-local' is
> given.\n"
> + " 1. Save the local change in the given PATHs to a patch file, and\n"
> + " revert that change from the WC unless '--keep-local' is given.\n"
> " If a log message is given with '-m' or '-F', include it at the\n"
> " beginning of the patch file.\n"
> "\n"
> - " 2. Delete the shelved patch NAME.\n"
> + " 2. Delete the shelved change NAME.\n"
> "\n"
> - " 3. List shelved patches. Include the first line of any log message\n"
> - " and some details about the contents of the patch, unless '-q'
> is\n"
> + " 3. List shelved changes. Include the first line of any log message\n"
> + " and some details about the contents of the change, unless '-q'
> is\n"
> " given.\n"
> "\n"
> - " Patch files are named .svn/shelves/NAME.patch\n"),
> + " The kinds of change you can shelve are those supported by 'svn
> diff'\n"
> + " and 'svn patch'. The following are currently NOT supported:\n"
> + " mergeinfo changes, copies, moves, mkdir, rmdir,\n"
> + " 'binary' content, uncommittable states\n"
svn patch supports binary content. The limitation here is probably that
currently only 'svn diff --git' produces the patches in the proper form, while
other invocations skip binary files.
Bert
Re: svn commit: r1806548 - in /subversion/trunk/subversion: svn/svn.c svnbench/svnbench.c tests/cmdline/basic_tests.py
Bert Huijben writes: >> As Julian discovered, '--search' as used with 'svn log' is may not suitable >> for 'svn ls'. File name matching should be case-sensitive and requires >> full patterns just like e.g. the ordinary unix command line 'ls' command. >> >> Therefore, introduce a separate '--pattern' option for 'svn log' that works >> similar to patterns with Unix command line 'ls'. Since the actual matching >> already confirms to that, we only need a different option pre-processing. > > Perhaps we could use --glob, to allow other syntax patterns later? > > Not sure... perhaps --glob is too technical. My 2 cents on this would be that having "svn ls --pattern" and "svn log --search" which only differ in terms of case sensitivity have a chance of being confusing for the users. Perhaps, a slightly better way would be to keep the case-insensitive behavior by default, but add a "--case-sensitive" switch to handle the cases where it's required? That is, svn ls --search svn ls --search --case-sensitive Regards, Evgeny Kotkov
Re: 'svn list --search' feature complete?
On Tue, Aug 29, 2017 at 12:08 PM, Stefan Fuhrmann wrote: > On 18.08.2017 13:36, Johan Corveleyn wrote: >> >> On Sun, Jan 29, 2017 at 10:35 AM, Stefan Fuhrmann >> wrote: >>> >>> On 24.01.2017 12:20, Stefan Sperling wrote: >> >> ... I would like to get an 1.10.0 alpha1 released in February. Unless I hear objections I will start rolling this alpha release from trunk and call a vote on it soon. >>> >>> >>> >>> Originally, I wanted to complete the get_list API before the alpha >>> release but I can't make any commitments. So, it is probably better >>> to roll the alpha with whatever is on /trunk at that time. >>> >>> -- Stefan^2. >> >> >> Hi Stefan2, >> >> Is the current state of the new get_list API complete on trunk now? Is >> the 'svn list --search' feature useable / good enough for beta? >> >> Context: on IRC we were talking about releasing a 1.10 beta, so this >> crossed my mind as one of the new features that might not be complete >> yet. >> >> BTW: 'svn list --search' isn't described in the release notes yet (and >> neither in CHANGES I believe). >> > > Sorry that had fallen off the edge of the disk for > the last couple of weeks. Been super busy and then > went fully off the grid for the last two weeks. > > r1806548 fixes the inconsistency that Julian found. Are you sure? As I understood from Julian's mail, the problem with the case-sensitivity really seemed like a bug: files with uppercase characters were simply not found, not even if the pattern was spelled out in uppercase. See the last one here below: > $ svn list | grep -i "^co" > COMMITTERS > configure.ac > contrib/ > > $ svn list --search 'co*' > configure.ac > contrib/ > > $ svn list --search 'CO*' > configure.ac > contrib/ So that looks like: you tried to make it case-insensitive (by converting the pattern to lowercase internally), but it doesn't work (because the paths are not converted similarly or something). (I haven't tested it myself) Orthogonally: I think case-insensitive matching would be nice to have as well (either always, or optionally with some flag / pattern prefix / ...). Use case: Windows user base, trying to search for files with an extension, like *.PNG, *.png, ... > r1806550 got the CHANGES updated. > > My plan is to complete the ra_serf implementation > this week. Let's hope no higher-prio SVN issue > interrupts that once more. Great! Thanks for making this work :-). -- Johan
RE: svn commit: r1806548 - in /subversion/trunk/subversion: svn/svn.c svnbench/svnbench.c tests/cmdline/basic_tests.py
> -Original Message- > From: stef...@apache.org [mailto:stef...@apache.org] > Sent: dinsdag 29 augustus 2017 11:57 > To: comm...@subversion.apache.org > Subject: svn commit: r1806548 - in /subversion/trunk/subversion: svn/svn.c > svnbench/svnbench.c tests/cmdline/basic_tests.py > > Author: stefan2 > Date: Tue Aug 29 09:56:31 2017 > New Revision: 1806548 > > URL: http://svn.apache.org/viewvc?rev=1806548&view=rev > Log: > As Julian discovered, '--search' as used with 'svn log' is may not suitable > for 'svn ls'. File name matching should be case-sensitive and requires > full patterns just like e.g. the ordinary unix command line 'ls' command. > > Therefore, introduce a separate '--pattern' option for 'svn log' that works > similar to patterns with Unix command line 'ls'. Since the actual matching > already confirms to that, we only need a different option pre-processing. Perhaps we could use --glob, to allow other syntax patterns later? Not sure... perhaps --glob is too technical. Bert
Re: 'svn list --search' feature complete?
On 18.08.2017 13:36, Johan Corveleyn wrote: On Sun, Jan 29, 2017 at 10:35 AM, Stefan Fuhrmann wrote: On 24.01.2017 12:20, Stefan Sperling wrote: ... I would like to get an 1.10.0 alpha1 released in February. Unless I hear objections I will start rolling this alpha release from trunk and call a vote on it soon. Originally, I wanted to complete the get_list API before the alpha release but I can't make any commitments. So, it is probably better to roll the alpha with whatever is on /trunk at that time. -- Stefan^2. Hi Stefan2, Is the current state of the new get_list API complete on trunk now? Is the 'svn list --search' feature useable / good enough for beta? Context: on IRC we were talking about releasing a 1.10 beta, so this crossed my mind as one of the new features that might not be complete yet. BTW: 'svn list --search' isn't described in the release notes yet (and neither in CHANGES I believe). Sorry that had fallen off the edge of the disk for the last couple of weeks. Been super busy and then went fully off the grid for the last two weeks. r1806548 fixes the inconsistency that Julian found. r1806550 got the CHANGES updated. My plan is to complete the ra_serf implementation this week. Let's hope no higher-prio SVN issue interrupts that once more. -- Stefan^2.
RE: [PATCH] Add XFail test for relocating working copy with removed externals
> -Original Message-
> From: Ivan Zhakov [mailto:i...@visualsvn.com]
> Sent: maandag 28 augustus 2017 15:26
> To: dev@subversion.apache.org
> Subject: [PATCH] Add XFail test for relocating working copy with removed
> externals
>
> Log message:
> [[[
> Add XFail test for relocating working copy with removed externals.
>
> Found by: TortoiseSVN dump
> Patch by: Ivan Zhakov {ivan {at} visualsvn.com}
>
> * subversion/tests/cmdline/relocate_tests.py
> (relocate_with_removed_externals): New test.
> (test_list): Add new test to the test list.
> ]]]
+1
Feel free to commit this.
I'll try to commit this later this week if you don't get to this. You can just
use your committer name in the Patch by line, to match things up in the
contribulyzer.
(Or just commit it if you feel like it;-))
Bert
Re: Towards a Shelving MVP
Daniel Shahaf wrote: > The fact that all these representations are interchangeable suggests to > me that they all have the same compatibility properties. [...] > > We need a format bump iff a db query in 1.10 wouldn't DTRT on a wc that > 1.11 has touched. I don't see why shelves would introduce any instance > of this — even if they add new DB tables. > > (I suppose 1.10 might purge pristines that are only used by shelves, but > then, the worst-case is that somebody who uses 1.10 and 1.11 on the same > working copy will need to re-fetch the pristine from the server.) OK, if all the info goes into new db tables. And it would be desirable to have a way to: * generate a diff from that storage, to output for review or as a patch. > > You mean, if we store shelves as unidiffs in .svn/shelves/, user can > cp(1) them from there? I think it would be good to require users to run > 'svn shelf --export-as-unidiff' to get a unidiff: it affords separation > of concerns (between the user-facing functionality and the backing > storage). Fair comment. > [...] > My overall impression is that diff3 is the so called king's road here: > it's designed for this and it's not all that more expensive than the > alternative. I agree in terms of the outcome. We'll need to see how expensive the implementation task to get there would be. Thanks, - Julian
