On Tue, Oct 26, 2004 at 07:45:37PM +0200, SteveKing wrote:
> >Yes, that's true. The solution is to treat them as files if they are
> >in a directory under subversion control (i.e. with a .svn folder), and
> >treat them as shortcuts (act on the target) when they are not.
>
> Wouldn't that confuse users? I mean they wouldn't really know why a
> shortcut sometimes 'works' and sometimes not (until they read the docs,
> but most won't do that but complain on the list instead or file issues).
I use this mode extensively with TortoiseCVS, and it is fine. It's
what people would expect, I think. The two use cases where it might
fail would be:
1. If you make shortcut within a version controlled tree, from
another version controlled tree, and didn't want to add that shortcut
to svn. This seems unlikely, and besides it is the same behaviour as
the current software.
2. If you make a shortcut somewhere not version controlled, and you
right click on it and want to version control it. That never happens.
And again, it is the same as the current behaviour, you just get
extra powers, none are being taken away.
> Also: the chance that such a shortcut is invalid is very high - and
> since NT4 (and Win2k in some cases) just crash if you try to follow such
> a link the whole shell process would go down with it, since TSVN is a
> shell extension. Bad, very bad...
Yeuch! Didn't know about that...
> >>I guess the second option here is better. But should I add another
> >>button as you suggested or add a checkbox with "stop on copy"?
> >
> >Yes, that sounds good.
>
> What exactly? The second button or the checkbox?
The checkbox sounds good as well, I don't have a strong opinion.
> >Ah, I'm confused here. I'm doing the log on just one file, which is
> >unlikely to have 7Mb of history. Are you talking about cases of
> >recursively logging the entire repository?
>
> You're used to CVS where each file has its own log history. Subversion
> is different: all files share the same history - the whole repository
> has global revision numbers. So if you fetch the log on a folder (e.g.
> the /trunk/ folder), then you'll get the log of every revision at least
> one file/folder below that folder has changed. There's no recursion done
> for that - the server just filters the log messages out for those
> changes not below the folder you've selected.
> In Subversion, it's common practice to show the log for the whole
> project folder. Only that way you can see what changed in the project,
> what's been going on. If you would just select one file, you would miss
> a lot of changes which are important for you, but happened to other files.
> Sure, if you show the log only for one file, the history won't be that
> big. But that's a rare case.
OK, I see. It's much more common to log a whole folder in Subversion,
because you can actually do so quickly. That's cool!
Even so, when I log one file, getting a truncated log by default seems
very odd to me. How far back does it truncate it?
Francis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Oct 26 21:30:10 2004