Shouldn't the second commit fail due to that developer's working copy
being out of date with the repository? If the change was 2 developers
making the same textual change to the same file, that scenario
wouldn't work.
At least from a user experience perspective, the behavior seems
ambiguous to say the least. Just curious what the rationale would be
behind SVN working this way (if this is indeed 'correct' behavior).
R.
On 10/22/07, Karl Fogel <kfogel@red-bean.com> wrote:
> Dmitry Konyshev <dmitry.konyshev@gmail.com> writes:
> > Is it considered correct that a change to an older revision that had
> > already been made in a newer revision creates an empty commit?
> > Specifically, we've just faced such situation: one developer removed a
> > directory and checked this in; another developer, without having
> > updated his working copy, removed the same directory and checked this
> > in either. As a result of the second commit, we got a revision which
> > doesn't have changed paths at all.
>
> I believe that is borderline correct -- it may also be incorrect :-).
> In other words, I'm not sure there's a convincing argument either way,
> though I haven't thought about the question deeply either.
>
> Although you have no changed paths in the second revision, you do have
> the log message, which may contain useful information not available
> elsewhere.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Oct 22 20:22:00 2007