Re: merge, --reintegrate, --record-only, near infinite regress in --use-merge-history

[Stefan Sperling <st...@elego.de>]

On Wed, Jun 02, 2010 at 11:33:21AM +0200, B Smith-Mannschott wrote:
> A few clever people suggested a way around the delete-and-recreate the
> branch problem. Just use a record-only merge to make the topic branch
> aware of the reintegration revision on trunk without actually enduring
> the resulting conflicts.
> 
> It sounded like a great idea when I read it. Very clever.
> 
> Unfortunately, it's also *very* *broken*.
> 
> This technique interacts badly with "svn log -g". After a few repetitions of
> merge, merge --record-only, merge --reintegrate, I'm finding the same
> revisions showing up over and over again in my trunk when using svn log -g.
> 
> svn log -q | wc -l
> 2299
> 
> svn log -q -g | wc -l
> 14167
> 
> $ svn log -q -g | egrep -o -e "^r[0-9]+" | sort | uniq -c | sort -n | tail
>     131 r42278
>     135 r42171
>     135 r42251
>     135 r42252
>     136 r42196
>     136 r42205
>     136 r42219
>     136 r42223
>     191 r42282 <-- these two revisions appear 191 times in the log -g of trunk!
>     191 r42292 <--
> 
> When this has made svn log -g useless for me. ("Include merged
> revisions" in TortoiseSVN is similarly useless). This is unfortunate,
> because I had hoped that this feature would free me from having to
> painstakingly protocol which revisions were merged in the log message
> as I used to do in 1.4 days.

On the surface, this doesn't look like a merge-tracking problem.
It smells more like a presentation-layer bug (in log -g).
We should figure out how log -g should behave in this case (the behaviour 
you're seeing clearly isn't desirable) and then fix it.
Please file an issue.

BTW, there's another known problem with the --reintegrate/--record-only trick,
with 2-URL merges: http://subversion.tigris.org/issues/show_bug.cgi?id=3648

Thanks,
Stefan

RE: Wanted: pre-commit hook to prevent commits to externals definition

[David Aldrich <Da...@EU.NEC.COM>]

Hi Ryan and Daniel

> Right. I don't think the server would be able to tell that a commit came
> from a working copy that, on the client side, had been created by an
> externals definition. I think it all looks the same to the server so I
> don't think such a hook script can be implemented.

Thank you both for your answers.

Best regards

David

Re: Wanted: pre-commit hook to prevent commits to externals definition

[Ryan Schmidt <su...@ryandesign.com>]

On Jun 3, 2010, at 18:34, Daniel Becroft wrote:

> On Fri, Jun 4, 2010 at 12:12 AM, David Aldrich <Da...@eu.nec.com> wrote:
> 
>> Please can anyone point me to an example of a svn pre-commit hook that prevents commits to files that are members of an externals definition?
>> 
>> We want to allow such files to be committed only from within the external directory, i.e. where they originate from.
> 
> I don't have an example of such a script. *But*, I'm not sure if even such a script could be possible. My understanding of committing w/ externals, is that the modifications to the externals are committed separately (or even excluded) from the main commit. This would certainly be the case for externals pointing to a separate repository, and may be the case .
> 
> I just did a quick test (with both intra- and inter-repository external definitions), and SVN does not seem to descend into the externals for a commit. The externals directory has to be explicitly committed, which makes it no different from a normal working copy. 

Right. I don't think the server would be able to tell that a commit came from a working copy that, on the client side, had been created by an externals definition. I think it all looks the same to the server so I don't think such a hook script can be implemented.

Re: Wanted: pre-commit hook to prevent commits to externals definition

[Daniel Becroft <dj...@gmail.com>]

On Fri, Jun 4, 2010 at 12:12 AM, David Aldrich <Da...@eu.nec.com>wrote:

> Hi
>
> Please can anyone point me to an example of a svn pre-commit hook that
> prevents commits to files that are members of an externals definition?
>
> We want to allow such files to be committed only from within the external
> directory, i.e. where they originate from.
>
> Best regards
>
> David
>

I don't have an example of such a script. *But*, I'm not sure if even such a
script could be possible. My understanding of committing w/ externals, is
that the modifications to the externals are committed separately (or even
excluded) from the main commit. This would certainly be the case for
externals pointing to a separate repository, and may be the case .

I just did a quick test (with both intra- and inter-repository external
definitions), and SVN does not seem to descend into the externals for a
commit. The externals directory has to be explicitly committed, which makes
it no different from a normal working copy.

Cheers,

Re: Wanted: pre-commit hook to prevent commits to externals definition

[Lorenz <lo...@yahoo.com>]

Daniel Becroft wrote:
>Lorenz wrote:
>> David Aldrich wrote:
>>>Please can anyone point me to an example of a svn pre-commit hook that prevents commits
>>>to files that are members of an externals definition?
>>>
>>>We want to allow such files to be committed only from within the external directory, i.e. where
>>>they originate from.
>>
>> As long as the externals are pointing to the same repository it should
>> be possible to examine the transaction and determine if any of the
>> changed paths is related to an external definition (external
>> properties can be extracted from the transaction too).
>
>Really? From my testing, it seemed that SVN doesn't descend into
>externals during a commit, regardless of whether the external points
>to the same or a different repository.
>
>Have you seen different behaviour?

yes and no 8-)

The command line client does not decend into externals, but you can
list the external folders additionally to get an atomic commit,

and I'm using TSVN as my main client, which lists externals from the
same repository in the commit dialog, selected for commit by default.
-- 

Lorenz

Re: Wanted: pre-commit hook to prevent commits to externals definition

[Daniel Becroft <dj...@gmail.com>]

On Mon, Jun 7, 2010 at 6:52 PM, Lorenz <lo...@yahoo.com> wrote:
> David Aldrich wrote:
>>Please can anyone point me to an example of a svn pre-commit hook that prevents commits
>>to files that are members of an externals definition?
>>
>>We want to allow such files to be committed only from within the external directory, i.e. where
>>they originate from.
>
> As long as the externals are pointing to the same repository it should
> be possible to examine the transaction and determine if any of the
> changed paths is related to an external definition (external
> properties can be extracted from the transaction too).

Really? From my testing, it seemed that SVN doesn't descend into
externals during a commit, regardless of whether the external points
to the same or a different repository.

Have you seen different behaviour?

Cheers,
Daniel B.

Re: Wanted: pre-commit hook to prevent commits to externals definition

[Lorenz <lo...@yahoo.com>]

David Aldrich wrote:
>Please can anyone point me to an example of a svn pre-commit hook that prevents commits
>to files that are members of an externals definition?
>
>We want to allow such files to be committed only from within the external directory, i.e. where
>they originate from.

As long as the externals are pointing to the same repository it should
be possible to examine the transaction and determine if any of the
changed paths is related to an external definition (external
properties can be extracted from the transaction too).
-- 

Lorenz

Wanted: pre-commit hook to prevent commits to externals definition

[David Aldrich <Da...@EU.NEC.COM>]

Hi

Please can anyone point me to an example of a svn pre-commit hook that prevents commits to files that are members of an externals definition?

We want to allow such files to be committed only from within the external directory, i.e. where they originate from.

Best regards

David

Re: merge, --reintegrate, --record-only, near infinite regress in --use-merge-history

[B Smith-Mannschott <bs...@gmail.com>]

On Wed, Jun 2, 2010 at 12:46, Stefan Sperling <st...@elego.de> wrote:
> On Wed, Jun 02, 2010 at 12:37:13PM +0200, Stefan Sperling wrote:
>> We should figure out how log -g should behave in this case (the behaviour
>> you're seeing clearly isn't desirable) and then fix it.
>> Please file an issue.
>
> Oh, and if you can, please write a small script (attached to the issue)
> or test case (patch for our test suite) that shows the problem,
> by triggering a single revision to appear too many times in log -g output.
> That would help people who would like to investigate get started.
>
> Thanks,
> Stefan
>

http://subversion.tigris.org/issues/show_bug.cgi?id=3650

Re: merge, --reintegrate, --record-only, near infinite regress in --use-merge-history

[Stefan Sperling <st...@elego.de>]

On Wed, Jun 02, 2010 at 12:37:13PM +0200, Stefan Sperling wrote:
> We should figure out how log -g should behave in this case (the behaviour 
> you're seeing clearly isn't desirable) and then fix it.
> Please file an issue.

Oh, and if you can, please write a small script (attached to the issue)
or test case (patch for our test suite) that shows the problem,
by triggering a single revision to appear too many times in log -g output.
That would help people who would like to investigate get started.

Thanks,
Stefan