Mark Phippard <markp@softlanding.com> wrote:
> Over on the Subclipse list (I also see this on users@ and TortoiseSVN
> lists) we have been getting a lot of activity from new users that are
> really confused by the out of date errors they get. I think we see
> this a lot more in Subclipse because the Eclipse IDE encourages
> refactoring which leads to a lot of moves and renames.
>
> The biggest problem we run into is with new users working alone with a
> repository. It is easy to understand how someone with one project
> and one working copy working by themselves can get confused by an
> error saying their project is out of date.
>
> This might be a crazy idea that goes against all of the design
> principles in the code, but would it be possible to enhance the
> commit process so that after committing revision N, any "parent
> folders" to the committed files that are at revision N - 1 be
> advanced to revision N? This would keep the folders at the HEAD
> revision unless another user makes commits to the repository. It
> seems safe on paper, but I do not know what the code implications
> would be.
>
> Just a thought, I'd appreciate any comments. I spend a lot of time
> explaining and defending this problem to users.
I thought about this problem as well, and I believe your solution is partial
and does not scale up that much (even if you think of project with just one
user, there's still the case of multiple projects in the repository, where the
N-1 -> N trick won't always work).
I think a better solution would be marking the working copy as "solid" at
check-out time. "solid" means that everything happens at top-level, even if you
are in a subdirectory. As an implementation detail, ".svn" directories in
subdirs might even disappear (but it's not necessary, it's just to explain
better what I mean); in other words, with a solid working copy I don't expect a
subdir to be a working a copy as well.
This would solve your problem because commits will be done top-level (even if
they affect only a few files) and will thus update all the subdirs correctly.
The same would hold true for update, of course. And I think it's a better
overall solution that your "quick hack".
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 1 03:18:19 2006