> -----Original Message-----
> From: Stefan Sperling [mailto:s...@apache.org]
> Sent: vrijdag 17 november 2017 14:26
> To: Sam White <sam94wh...@gmail.com>
> Cc: dev@subversion.apache.org
> Subject: Re: [RFC] svn commit --parents option needed
>
> On Tue, Nov 14, 2017 at 03:57:45PM +0000, Sam White wrote:
> > Hi Developers,
> >
> > I propose the addition of an equivalent to the --parents option to "svn
> > commit", to check in the directory structure as well as any files
> > specified.
> >
> > I understand that with svn add, the --parents option is available.
However,
> > the use case I have in mind is one that I come across quite often,
> > involving changelists and SVN moves.
> >
> > If I add files to changelist, I expect to be able to commit any changes
to
> > them quickly and easily - that's the point, right? But if I perform an
SVN
> > move on these items, to a directory which is not yet committed, because
I
> > cannot yet add directories to the changelist, when I go to commit the
> > files, I get the error
> >
> > svn: E200009: '/some/new/directory/here' is not known to exist in the
> > repository and is not part of the commit, yet its child
> > '/some/new/directory/here/file_on_changelist.txt' is part of the commit
> >
> > If I then try and commit those files, as sort of a "pre-commit" commit,
> > then i get the error
> >
> > Cannot commit '/some/directory/here' because it was moved from
> > '/other/directory/here/' which is not part of the commit; both sides of
the
> > move must be committed together
> >
> > The workaround for this seems to involve a mess of committing these
> > directories together, with the option --depth=empty, and then committing
> > with the changelist. Alternatively, I could just skip the --depth=empty,
> > and let the commit handle the fiels as well - but then, what was the
point
> > in making a changelist? I still end up formulating some long command!
> >
> > I was asking about this in the #svn IRC - here is the chat log:
> > http://colabti.org/irclogger/irclogger_log/svn?date=2017-11-14#l21
> >
> > Is what I am suggesting clear? I'd appreciate your thoughts.
> >
> > Thanks,
> >
> > Sam (sixquidsquid)
>
> So to reiterate:
>
> I move a directory which contains some files which belong to a
> changelist and some which do not belong to this changelist.
>
> I now want to use commit --cl in order to commit the modifications in
> the files listed in my changelist. Because some or all of these files
> sit inside the moved directory I have to commit this move as well.
>
> In the repository, the moved directory will be both copied to
> the new location and deleted at its old path in this same commit.
>
> And a server-side directory copy is always recursive; there is no
> way to exclude any children from the copy unless we're explicitly
> marking them deleted in the copy target.
> So some files which are not part of my changelist will be moved along.
>
> Is your goal to *only move the files* which are part of your changelist?
> I believe this could not be made to work without lots of headache.
>
> Or is your goal to perform the directory move recursively, and in the
> same revision commit modifications to only those files which are part
> of the changelist? I believe this can be made to work.
>
> I'll note that the current behaviour in the case where a changelist
> contains a file which has been moved directly, rather than having
> been moved along with a parent directory, supports your feature
> request because this case already "just works":
>
> $ svn cl my-file alpha
> A [my-file] alpha
> $ echo foo >> alpha
> $ svn mv alpha alpha2
> A alpha2
> D alpha
> $ svn st
>
> --- Changelist 'my-file':
> D alpha
> > moved to alpha2
> A + alpha2
> > moved from alpha
> $ svn ci alpha2
> $ svn ci --cl my-file -m "edit and move alpha"
> Deleting alpha
> Adding alpha2
> Transmitting file data .done
> Committing transaction...
> Committed revision 3.
How would this be affected by property changes on parent directories? Should
these be committed or not when using --parents. Especially around changes to
svn:mergeinfo this could be pretty interesting as it would make it much
easier to commit only some parts of a merge without warning.
Bert
