On Fri, Sep 07, 2018 at 01:18:08PM +0300, Timur Khanipov wrote:
> Hi, folks.
>
> I have successfully used Subversion for many years and in general I am
> happy with it, so I have always defended this VCS when my friends or
> colleagues argued in favor of git and other things. But today I stepped
> into a very unpleasant situation which I would like to clarify.
> I have made a large change to my working copy. I would love to have created
> a branch and made a series of little neat commits instead but I could not
> due to a specific 'trunk based development' policy of my new employer.
> Neither could I commit to trunk because my new colleagues would not approve
> the code review unless it contains all the necessary stuff -- unit tests,
> etc. So I had around 10 files pending modified and around 10 files which
> were copied/removed/moved. Pretty uncomfortable situation, if you ask me --
> again, I would really, really love to have it all sequentially commited in
> a feature branch.
You should really be using feature branches for this use case.
If this example doesn't convince your employer to reconsider their
silly trunk-only stance, then I don't know what else to recommend.
> Then I needed to revert all the changes in the working copy to check if one
> test which failed with my changes, worked. I used the following sequence of
> commands:
> $ svn diff > my.patch
> $ svn revert -R .
> $ # ... check the test ...
> $ svn patch my.patch
>
> Afther applying the `svn patch` command I got a bunch of tree conflict
> situations and rejected hunks of modifications. I am now preparing myself
> to deal with this somehow (probably by manually copying/moving the files
> first and then re-applying the patch) but first I decided to check what
> happened. It seems like `svn diff` cannot produce a patch which would
> preserve copy/move information. I tested this hypothesis in a separate repo
> and it proved true. During my tests I discovered the `svn shelve` command
> which is supposed to do precisely what I needed and its description states
> "The kinds of change you can shelve are those supported by 'svn diff' and
> 'svn patch'. The following are currently NOT supported: mergeinfo changes,
> copies, moves, mkdir, rmdir, 'binary' content, uncommittable states", so
> indeed Subversion could not do what I wanted it to do.
Study your tools and file formats well before relying on them for
important data. These limitations are rooted in the unidiff file format
which 'svn patch' implements.
There are various extensions to this format made in git and other tools
which are partly supported by SVN, too. But what you're asking for is
not trivial for a number of reasons.
'svn patch' is intended to help projects who get patch submissions on
their mailing list, it is not a replacement for 'svn copy' and 'svn merge'.
> Not only the described behavior contradicts the principle of least
> astonishment, there is no way (by supplying specific flags to `svn
> diff/patch`) of making Subversion save the full change and restore it. This
> is at least disappointing.
The shelving feature is marked experimental for this reason.
> Are there any plans to tackle this issue?
As far as I know the shelving feature is still under active developmen.
But we cannot promise neither specific deliverables nor a specific
timeline for improvements to be made. Subversion is a mostly volunteer
project these days and resources are limited.
You are of course welcome to pitch in and help out :-)
>
> Regards,
> Timur Khanipov
>
> P.S. I am using Subversion version 1.10.0, r1827917.
Received on 2018-09-07 12:43:16 CEST