I (Julian Foad) wrote:
> On Thu, 2011-06-23 at 13:33 +0200, Bert Huijben wrote:
> >
> > > -----Original Message-----
> > > From: Julian Foad [mailto:julian.f...@wandisco.com]
> > > Sent: donderdag 23 juni 2011 12:37
> > > To: Subversion Development
> > > Subject: API review - the 'commit_as_operations' flag on
> > > svn_client_commit5()
> > >
> > > I'd like to understand the new 'commit_as_operations' flag on
> > > svn_client_commit5() a bit better. First, note that the old commit4()
> > > API passes FALSE. The doc string says:
> > >
> > > * If @a commit_as_operations is set to FALSE, when a copy is committed
> > > * all changes below the copy are always committed at the same time
> > > * (independent of the value of @a depth). If @a commit_as_operations is
> > > * #TRUE, changes to descendants are only committed if they are itself
> > > * included via @a depth and targets.
> > > *
> > > * When @a commit_as_operations is #TRUE it is possible to delete a node
> > > and
> > > * all its descendants by selecting just the root of the deletion. If it
> > > is
> > > * set to #FALSE this will raise an error.
> > >
> > > So the commit_as_operations flag tells Subversion to commit a copy or
> > > delete of a directory as a tree operation, without the caller having to
> > > specify the children of the tree (individually or by setting 'depth' to
> > > a big enough depth).
> > >
> > > The implementation does two things with this flag. It suppresses a
> > > check for deleting a directory with insufficient depth specified; and it
> > > suppresses passing "recurse=TRUE" to svn_wc_queue_committed3(), which
> > > it
> > > would otherwise do when queueing a copied directory.
> > >
> > > The check for delete is all that's necessary for delete. But for copy,
> > > the recurse=TRUE only applies to post-processing the WC after the
> > > commit, so how does this affect what gets committed? It doesn't seem to
> > > pass the flag to _harvest_committables() or svn_client__do_commit() or
> > > anything before the post-processing.
> >
> > If you commit a copy passing FALSE (and depth < infinity) will commit
> > all text (and other) changes in descendants of the copy, like how we
> > handled commit in 1.6.
> >
> > If you pass TRUE (and depth < infinity) only the changes in selected
> > descendants will be committed.
> >
> > So assuming --depth empty and only the root of a copy passed as
> > argument:
> > * With TRUE: The copy is committed and local modifications of
> > descendants are left as modifications for a future commit. (WC-NG
> > status changes from ADD to Modified. Normal status From M+ to M)
> > * With FALSE: all changes in descendants are committed together with
> > the parent. (Everything goes to status normal).
>
> Bert: in my test with the attached script and compiled with
> svn_client_commit5() passing FALSE, I find that the changes in
> descendants of my copied directory 'A/B2' are NOT committed, and instead
> those changes seem to be reverted in the WC. (So everything goes to
> status normal :-) Can you try this?
This is what I see:
[[[
$ rm -rf repo/ wc/; ./test-committing-copied-dir.sh
Checked out revision 0.
A A
A A/B
A A/B/C
A A/B/f
Adding A
Adding A/B
Adding A/B/C
Adding A/B/f
Transmitting file data .
Committed revision 1.
A A/B2
property 'p' set on 'A/B2/C'
A A/B2/C/D
Adding A/B2
svn: The depth of this commit is 'empty', but copies are always performed
recursively in the repository.
Committed revision 2.
$ svn st -v wc
0 0 ? wc
1 1 julianfoad wc/A
1 1 julianfoad wc/A/B
1 1 julianfoad wc/A/B/C
1 1 julianfoad wc/A/B/f
2 2 julianfoad wc/A/B2
2 2 julianfoad wc/A/B2/C
2 2 julianfoad wc/A/B2/C/D
2 1 julianfoad wc/A/B2/f
$ cd wc
$ svn up
Updating '.':
At revision 2.
$ svn ls -R
A/
A/B/
A/B/C/
A/B/f
A/B2/
A/B2/C/
A/B2/f
$ svn ls -R ^/
A/
A/B/
A/B/C/
A/B/f
A/B2/
A/B2/C/
A/B2/f
$ svn cat ^/A/B2/f
$ cat A/B2/f
hello
]]]
- Julian
