On Sun, Aug 29, 2021 at 9:04 AM Branko Čibej <br...@apache.org> wrote: > > On 29.08.2021 14:21, Mark Phippard wrote: > > On Sun, Aug 29, 2021 at 8:12 AM Branko Čibej <br...@apache.org> wrote: > >> On 27.08.2021 15:55, Evgeny Kotkov wrote: > >> > >>> 1. Complete the work on ^/subversion/branches/multi-wc-format so that > >>> the > >>> client would work with both the new and old working copy formats, > >>> for > >>> a seamless user experience and better compatibility. > >> This basically needs the following: > >> > >> * a huge sync with trunk; > >> * a way to pass the requested WC format from the command-line into the > >> WC library when creating a working copy (I never found a nice, clean > >> way to do that); > >> * an actual test for WC compatibility. > > I was giving this some thought yesterday and was thinking an option on > > the checkout command would be enough to get started. We can bikeshed > > the name of the option but to borrow a somewhat similar term from git > > imagine something like: > > > > $ svn co --shallow $url . > > > > Personally, I think this would be enough to release the feature but it > > would obviously also be nice if there were ways to convert a WC > > to/from this format. Maybe with options on the update or switch > > commands? > > Adding options on the command-line is not the issue. The issue is > cleanly sending those options into the WC layer; i.e., it's a code > architecture issue, not a UI issue.
Thanks for that explanation, hopefully a solution reveals itself. > The branch already introduces an option to select the WC format on > checkout. We don't need any new options for other commands since we have > "svn upgrade" and it should remain the only way to change the format of > an existing working copy. Accordingly, the WC format option should be > ignored by checkout if the WC already exists. > > Whether or not we should allow downgrades (within supported versions) is > not something I'd want to consider at this point. My gut feeling says "no". I agree. If someone wanted to tackle it ... fine ... but it does not seem necessary to me and seems like it would just complicate things in ways that are not needed yet. Mark
