rooneg@gmail.com wrote on 08/01/2006 10:29:15 AM:
> On 7/31/06, 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.
>
> I believe the problem with that is that automatically updating those
> parent folders could potentially result in conflicts when the user is
> not in a position to deal with them. Running a commit on a
> subdirectory shouldn't cause conflicts in parent directories.
I was not suggesting it do an actual update command. When you do a
commit, at the end of the commit, something runs to update the entries
file for the new revision information for those files. What I was
suggesting was that if you committed revision N and the folder is at
revision N - 1, then perhaps this same process could also update the
entries file for the folder so that it was now also at revision N. If the
folder revision was anything other than N - 1, then it would not touch it.
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 16:37:08 2006