You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2001/11/26 21:45:18 UTC
Another bikeshed, another show...
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Another bikeshed, another show...
Posted by Mattias Rönnblom <ho...@lysator.liu.se>.
Ben Collins-Sussman <su...@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
Re: Another bikeshed, another show...
Posted by Yoshiki Hayashi <yo...@xemacs.org>.
Ben Collins-Sussman <su...@collab.net> writes:
> 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.
I prefer this one. This cleary states the status of working
copy. Copy is likely to happen less than modify so I don't
think it is too much.
--
Yoshiki Hayashi
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org