"Giovanni Bajo" <email@example.com> wrote on 07/31/2006 09:17:46 PM:
> Mark Phippard <firstname.lastname@example.org> 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
> and does not scale up that much (even if you think of project with just
> user, there's still the case of multiple projects in the repository,
> N-1 -> N trick won't always work).
> I think a better solution would be marking the working copy as "solid"
> check-out time. "solid" means that everything happens at top-level, even
> are in a subdirectory. As an implementation detail, ".svn" directories
> subdirs might even disappear (but it's not necessary, it's just to
> better what I mean); in other words, with a solid working copy I don't
> subdir to be a working a copy as well.
> This would solve your problem because commits will be done top-level
> they affect only a few files) and will thus update all the subdirs
> The same would hold true for update, of course. And I think it's a
> 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.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Aug 1 03:27:40 2006