[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Should commit take --depth?

From: Lieven Govaerts <svnlgo_at_mobsol.be>
Date: 2007-07-01 18:33:26 CEST

Karl Fogel wrote:
> Should commit accept all possible values of --depth?
> Right now, commit takes -N. The purpose of that is to allow someone
> to commit a property change on a directory without committing changes
> to files or subtrees under that directory.
> (Most other commands treat -N like --depth=files, but commit is
> special: 'svn commit -N DIR' doesn't commit modified files in DIR, it
> just commits any propchanges on DIR. This is not what you'd expect
> from reading svn_client_commit4()'s doc string, which currently says:
> "If @a recurse is false, subdirectories of directories in @a targets
> will be ignored". My testing indicates that that doc string is just
> mistaken, and I'll fix it appropriately depending on the outcome of
> this thread.)
> Let's consider what full --depth behavior might look like for commits:
> --depth=empty: Like today's -N.
> --depth=files: Like depth=empty, plus also commits any modified
> files directly inside a named directory target.
> --depth=immediates: Like depth=files, plus commits propchanges on
> any subdirectories of a named directory target.
> --depth=infinity: Full recursion, the default.
> Now the $64,000 question: are depth=files and depth=immediates really
> useful? I can see use cases for depth=empty and depth=infinity, but
> what would we really gain by supporting the other two?
What is the reason not to include it? Technical objections? Scope
limiting for 1.5?

I'm sure that even if we can't think of a specific usage scenario, some
users will try it and then be confused why --depth for commit is not
behaving the same way as for update or status.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 1 18:29:34 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.