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

RE: update --dry-run (again) [Was: Know before downloading trunk how many files I'm going to download.]

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Fri, 17 Oct 2008 16:04:44 +0200 (Jerusalem Standard Time)

I realize it's a workaround, not a solution, but doesn't

    "svn merge -r BASE:HEAD --dry-run . ."

do approximately what you would want 'svn up --dry-run' to do?

Daniel

Rob Hubbard wrote on Fri, 17 Oct 2008 at 14:57 +0100:
>
>
> > I may be missing something obvious, but what would svn update
> > --dry-run provide which svn status -u would not? svn st -u
> > shows what's changed locally and what's changed in the
> > repository, so one could see where conflicts might arise upon
> ^^^^^
> > updating, no?
> >
>
>
> Well, as you said, and as I commented in
> <http://svn.haxx.se/users/archive-2006-10/0465.shtml>,
> $ svn st -u
> shows where conflicts *might* occur.
>
> On the other hand,
> $ svn up --dry-run
> would show where they *will* occur.
>
> Given that SVN already provides --dry-run for merge,
> I'm surprised that there is so much resistance to introducing this
> option for the update command.
>
> My impression is also that other users would find this option useful
> for other reasons.
>
> I'd *also* quite like to see the remote changes without my local
> changes,
> that is, show what files will be updated to my working copy
> irrespective of my local changes. That's a slightly separate issue.
>
>
> Thanks,
> Rob.
>
> _______________________________________________
> This email has been scanned for Softel by Star.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-10-17 16:05:17 CEST

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

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