Stefan Sperling wrote:
> On Fri, Apr 25, 2008 at 11:24:12AM +0100, Julian Foad wrote:
>
>>Subcommand 'switch' doesn't accept option '--dry-run'
>
> Oh, sorry! I assumed it did, but I didn't check :/
>
> We should add probably --dry-run to both update and switch on
> the tree-conflicts branch to support this use case. Issue? :)
No, at least not on the tree-conflicts branch. I don't think this is a real
feature request (yet); at the moment we're only speculating that it might be a
useful feature. And it's not trivial - have you seen how the "merge" code tries
to keep track of items that are present on disk but would have been deleted by
now if this were not a dry run?
> So Aaron, I'm afraid that for now, checking for unversioned
> files after a switch/update is the only workaround I know :(
>
>
>>>With tree-conflict detection in place (i.e. not with 1.5, nor
>>>trunk, but our experimental tree-conflicts branch), this will
>>>notify you about conflicts, i.e. you'll see directories flagged
>>>as 'C'. (*lightbulb* Hmmm.... we might actually want to print a
>>>summary of all potential conflicts of any kind after any --dry-run
>>>operation... Cc'ing Julian Foad. Julian, do think this would be
>>>a good idea?)
>>
>>So, in the scenario where you "merge" or "switch" or "update" with
>>"--dry-run" (let's say that were supported), and get thousands of "M"od,
>>"D"el, and "A"dd notifications, and perhaps a few "C"onflicts as well, you
>>want to see at least something like:
>>
>>[[[
>>$ svn <merge|switch|update|whatever> --dry-run ...
>>M a.c
>>M b.c
>>C c.c
>>[...]
>>D foo
>>M bar
>>M baz
>>svn: There were conflicts.
>>]]]
>>
>>(and maybe more detail)?
>
>
> Exactly. Maybe some stats?
>
> $ svn <merge|switch|update|whatever> --dry-run ...
> M a.c
> M b.c
> C c.c
> [...]
> D foo
> M bar
> M baz
> svn: There were conflicts:
> 5 text conflicts
> 1 property conflict
> 2 tree conflicts
>
> Or even print affected paths as well:
>
> svn: There were conflicts:
> 5 text conflicts
> c.c
> xyz
> a/b/c
> parser/parse.c
> security/ssl/ssl.c
> 1 property conflict
> bar
> 2 tree conflicts (showing victims)
> foo
> baz/bay/bax.c
This just duplicates the information already printed by the lines that begin
with "C". We might as well keep the same format.
> This should happen regardless of --dry-run.
Yes, if we're going to repeat the "conflicts" information at the end of the
run, because it's more important than the rest of the output, then I agree we
should do it just the same in real runs as in dry runs.
> I suppose doing this would magnify svn's user-friendliness at
> a non-trivial degree, especially given that with 3 different
> types of conflicts, conflict handling will be getting a lot
> more complicated than it currently is. Note though that interactive
> conflict resolution makes it possible to resolve text (and property?)
> conflicts right during the update process, so depending on how people
> use this feature (and how we make it work with tree conflicts) the
> above example output may be redundant in the non-dry-run case.
Er... I don't really understand what you're saying, but note that we can't
assume that people will resolve all their conflicts interactively.
> Julian, should I open a tree-conflict issue for this, also,
> or append to an existing one? We should consider this when
> we get to the "cleaning up the UI" part.
You could append to the existing issue about tree conflicts UI, a note that it
would be nice to summarise conflicts at the end of the output. I don't see it
as necessary at this stage, just an optional enhancement.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-25 14:37:08 CEST