Hi, Stefan!
Thank you very much for a thorough explanation. I hope the
'shelve/unshelve' commands will eventually mature and be able to handle the
situation I described. I also think that these command should finally learn
to save modifications to a separate wc-independent file so that it would be
possible to share changes with colleagues without commiting. It would be
like a better (in some sense) implementation of 'svn diff/patch', capable
of snapping every change precisely as it is. Pitching in could be fun and
maybe I would allocate a time slot for that some day.
One more thought about 'svn diff/patch' in the "ideal world". If there is a
possibility of extending the diff format in a backward-compatible manner
(for example, by special messages in 'comments', if there are 'comments',
i.e. unused lines), then I definitely think that in future 'svn diff/patch'
should by default save and restore full modification information. If such
backward-compatible extension is impossible though, then developing 'svn
shelve/unshelve' is the only way.
Finally, I would like to say that the story had a happy ending. My employer
recently introduced a special internal feature ("intellectual"
shelve/unshelve) designed precisely for what I needed. Moreover, I was able
to restore my changes by unshelving from the patch I threw into the code
review system, so in the end I came up with exactly the same working copy
state.
Cheers,
Timur
пт, 7 сент. 2018 г. в 13:42, Stefan Sperling <stsp_at_elego.de>:
> 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 14:21:36 CEST