empty commits

[Dmitry Konyshev <dm...@gmail.com>]

Hello,

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.

Regards,
Dmitry

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: empty commits

[Rob van Oostrum <rv...@gmail.com>]

If anyone cares: here's a thread from last year:

http://svn.haxx.se/dev/archive-2006-03/0806.shtml

On 10/22/07, Karl Fogel <kf...@red-bean.com> wrote:
> "Rob van Oostrum" <rv...@gmail.com> writes:
> > 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).
>
> Yeah... Double-delete has long been a special case.  In some contexts,
> it should maybe conflict, in others, a conflict would be an annoyance.
> It's possibly only because of implementation concerns that making the
> same textual change conflicts while double-delete doesn't.  That's a
> bit lame, and I'm not saying that I'm sure this is the right behavior,
> just that Subversion has long behaved this way, and that the issue has
> been discussed before.  You might be able to dig up those past
> discussions in the archives; they might shed some more light on this.
>
> Best,
> -Karl
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: empty commits

[Karl Fogel <kf...@red-bean.com>]

"Rob van Oostrum" <rv...@gmail.com> writes:
> 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).

Yeah... Double-delete has long been a special case.  In some contexts,
it should maybe conflict, in others, a conflict would be an annoyance.
It's possibly only because of implementation concerns that making the
same textual change conflicts while double-delete doesn't.  That's a
bit lame, and I'm not saying that I'm sure this is the right behavior,
just that Subversion has long behaved this way, and that the issue has
been discussed before.  You might be able to dig up those past
discussions in the archives; they might shed some more light on this.

Best,
-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: empty commits

[Rob van Oostrum <rv...@gmail.com>]

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 <kf...@red-bean.com> wrote:
> Dmitry Konyshev <dm...@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

Re: empty commits

[Karl Fogel <kf...@red-bean.com>]

Dmitry Konyshev <dm...@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