Ben Collins-Sussman <sussman@collab.net> writes:
> OK, I may regret this, but here's another bikeshed UI question.
>
> Here's the 'simple' scenario:
>
> 1. I make local mods within a directory called 'foodir'.
>
> 2. 'svn mv foodir bardir'
>
> This rename is really 'svn cp foodir bardir && svn rm foodir'.
>
> 3. When I run 'svn status', what should I see?
>
>
> Note that when a directory is copied within the working copy, all of
> its entries are marked "copied=TRUE". This state exists independently
> of any schedule or existence flag. It simply means that the subtree
> overall will be added 'with copy history' during the next commit.
>
> Right now, 'svn status' would show this:
>
> A 2 ./bardir
> A 2 ./bardir/alpha
> A 2 ./bardir/beta
> A 2 ./bardir/gamma
> D 2 ./foodir
>
> That's because we've told status to print an "A" whenever it sees the
> "copied" flag.
>
> Of course, this is bogus I think. If "copied" is truly independent of
> any scheduling, we should be able to see our local mods within the
> copied directory, not cover them up! For example:
>
> A 2 ./bardir
> _ 2 ./bardir/alpha
> _ 2 ./bardir/beta
> _ 2 ./bardir/gamma
> D 2 ./foodir
>
> ...is what I should see if I have no local mods inside bardir, and...
>
> A 2 ./bardir
> M 2 ./bardir/alpha
> _ 2 ./bardir/beta
> _ 2 ./bardir/gamma
> D 2 ./foodir
>
> ... is what I should see if I've tweaked alpha's text as well.
>
> Here's the issue: Karl and Mike are of the opinion that this isn't
> enough; that we not only want to see the local mods in the copied
> subtree, but also see some markers that show the copied subtree
> itself. In other words, they want to see the 'copied' flag
> independently of the schedule flag. One solution might be to add
> another column:
>
> A A 2 ./bardir
> M A 2 ./bardir/alpha
> _ A 2 ./bardir/beta
> _ A 2 ./bardir/gamma
> D 2 ./foodir
>
> Now the eye can see a "block" of paths that remind one that a subtree
> is scheduled for addition-with-history; but at the same time, one can
> see the mods within the directory as well.
>
> Is this good? Or is it too much? In theory, if one sees a directory
> scheduled for addition and something with an 'M' inside it, one can
> infer that it must be a copied subtree. On the other hand, nobody
> likes to look at paths and deduce what is within what. The 'block'
> of A's is easier to see.
>
>
Hi.
Another way to put it would be showing
M 2 ./bardir
_ 2 ./bardir/alpha
_ 2 ./bardir/beta
_ 2 ./bardir/gamma
And the explantion is: the user has modified directory currently
named bardir (formerly known as foodir). He has changed the name.
In that way one suggests that a directory has some other id than
the path name. I don't know if that fits with the underlying
versioned versioned filesystem layer. It certainly doesn't
fit with "mv is cp && rm"...
//Mattias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:49 2006