"Giovanni Bajo" <rasky@develer.com> wrote on 07/31/2006 09:17:46 PM:
> Mark Phippard <markp@softlanding.com> wrote:
> > 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".
Good point about multiple projects causing problems for my idea. But I
fail to see how your idea changes anything. If there are multiple users
committing to the same project, then a commit from the root of the working
copy still cannot just update the folders as the updates from the other
users would still need to be brought down using update.
Someone on the Subclipse list pointed out that ClearCase will invoke a
merge when it encounters this scenario, so that you are prompted to update
the folders first. Eclipse has a Synchronize view which essentially could
do this, but one of the problems we deal with is that the svn status API
that we use to populate the view does not really give back out of date
folders (unless they have prop changes). If we could do a good job
showing this information in that view, it would probably be a decent
solution, although I still think that reducing the out of date scenario
would also help.
Mark
---------------------------------------------------------------------
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:27:40 2006