This application has halted due to an unexpected error.

[Angst, Hannes]

This application has halted due to an unexpected error.
A crash report and minidump file were saved to disk, you can find them here:
C:\Users\hangst\AppData\Local\Temp\svn-crash-log20160226121823.log
C:\Users\hangst\AppData\Local\Temp\svn-crash-log20160226121823.dmp
Please send the log file to users@subversion.apache.org to help us analyze
and solve this problem.

NOTE: The crash report and minidump files can contain some sensitive information
(filenames, partial file content, usernames and passwords etc.)


svn: E155037: Previous operation has not finished; run 'cleanup' if it was 
interrupted


svn-crash-log20160226121823.log
Description: svn-crash-log20160226121823.log


svn-crash-log20160226121823.dmp
Description: svn-crash-log20160226121823.dmp

Modifying svn:log property: good or bad?

[Alfred von Campe]

Is modifying the unversioned svn:log property considered bad practice?  We’re 
about to upgrade to a new Subversion server at work, and the central group that 
manages that server will no longer allow modifications to unversioned 
properties.  Their main reason is so that third party tools like Jira and 
Crucible, that have daemons that scan check-in comments for keywords and index 
the results, don’t have to be re-run again to re-index updated commits.  They 
are recommending creating a property on all the files that were affected in a 
commit (the name/value of the property is not important), and then committing 
that change with the “correct” check-in comment.  I can see their point, but 
sometimes you just want to correct a minor typo in a commit log.

I’m just wondering what collective wisdom of this group is in regards to 
updating the svn:log property (or other unversioned properties)?

Thanks,
Alfred

Re: Modifying svn:log property: good or bad?

[Eric Johnson]

We looked at this problem, and decided that typos were not sufficient
reason to tamper with history.

However, committers sometimes forget critical information, such as the bug
# associated with a commit, or other information critical to a useful audit
trail.

To avoid losing history, and yet allow for such critical information, our
work-around is to allow changes to the svn:log property, but *only* allow
appending to existing contents. Once we put that in, people stopped
complaining.

We don't allow users to change any other revprops.

Eric.

On Fri, Feb 26, 2016 at 7:40 AM, Alfred von Campe 
wrote:

> Is modifying the unversioned svn:log property considered bad practice?
> We’re about to upgrade to a new Subversion server at work, and the central
> group that manages that server will no longer allow modifications to
> unversioned properties.  Their main reason is so that third party tools
> like Jira and Crucible, that have daemons that scan check-in comments for
> keywords and index the results, don’t have to be re-run again to re-index
> updated commits.  They are recommending creating a property on all the
> files that were affected in a commit (the name/value of the property is not
> important), and then committing that change with the “correct” check-in
> comment.  I can see their point, but sometimes you just want to correct a
> minor typo in a commit log.
>
> I’m just wondering what collective wisdom of this group is in regards to
> updating the svn:log property (or other unversioned properties)?
>
> Thanks,
> Alfred
>
>

Re: Modifying svn:log property: good or bad?

[Alfred von Campe]

Eric:

Thanks for the feedback.  Do you enforce just appending to the svn:log property 
or is that just the policy and everyone follows it?  Same question for 
modifying the other recprops: do you enforce it or is it just policy?

Alfred

> On Feb 26, 2016, at 12:42, Eric Johnson  wrote:
> 
> We looked at this problem, and decided that typos were not sufficient reason 
> to tamper with history.
> 
> However, committers sometimes forget critical information, such as the bug # 
> associated with a commit, or other information critical to a useful audit 
> trail.
> 
> To avoid losing history, and yet allow for such critical information, our 
> work-around is to allow changes to the svn:log property, but only allow 
> appending to existing contents. Once we put that in, people stopped 
> complaining.
> 
> We don't allow users to change any other revprops.
> 
> Eric.
> 
> On Fri, Feb 26, 2016 at 7:40 AM, Alfred von Campe  > wrote:
> Is modifying the unversioned svn:log property considered bad practice?  We’re 
> about to upgrade to a new Subversion server at work, and the central group 
> that manages that server will no longer allow modifications to unversioned 
> properties.  Their main reason is so that third party tools like Jira and 
> Crucible, that have daemons that scan check-in comments for keywords and 
> index the results, don’t have to be re-run again to re-index updated commits. 
>  They are recommending creating a property on all the files that were 
> affected in a commit (the name/value of the property is not important), and 
> then committing that change with the “correct” check-in comment.  I can see 
> their point, but sometimes you just want to correct a minor typo in a commit 
> log.
> 
> I’m just wondering what collective wisdom of this group is in regards to 
> updating the svn:log property (or other unversioned properties)?
> 
> Thanks,
> Alfred
> 
> 

Re: This application has halted due to an unexpected error.

[Stefan]

Hi Hannes,

This application has halted due to an unexpected error.
A crash report and minidump file were saved to disk, you can find them here:
C:\Users\hangst\AppData\Local\Temp\svn-crash-log20160226121823.log
C:\Users\hangst\AppData\Local\Temp\svn-crash-log20160226121823.dmp
Please send the log file to users@subversion.apache.org to help us analyze
and solve this problem.

NOTE: The crash report and minidump files can contain some sensitive information
(filenames, partial file content, usernames and passwords etc.)


svn: E155037: Previous operation has not finished; run 'cleanup' if it was 
interrupted
From the log I see that you are running SlikSVN 1.8.9. Maybe you wanna 
give the latest build a try, since that version is quite old.


Unfortunately I won't have the time to look into the crashdump atm, 
therefore I can't estimate how likely it is that the issue you had will 
be solved with the upgrade.


Regards,
Stefan

Re: Modifying svn:log property: good or bad?

[Eric Johnson]

We definitely enforce restrictions. We also log all revprop changes.

Keep in mind that this information is key to establishing a historical
record of what happened with your source code. If you're lawyers haven't
advised you already, you might want to consider what happens if you ever
get hauled into court, and need to testify about the quality of the
historical information in your Subversion repositories. You want to keep
the list of people that can change the revprops (and the revisions
themselves) to an absolute minimum.

Eric.


On Fri, Feb 26, 2016 at 10:03 AM, Alfred von Campe 
wrote:

> Eric:
>
> Thanks for the feedback.  Do you enforce just appending to the svn:log
> property or is that just the policy and everyone follows it?  Same question
> for modifying the other recprops: do you enforce it or is it just policy?
>
> Alfred
>
> On Feb 26, 2016, at 12:42, Eric Johnson  wrote:
>
> We looked at this problem, and decided that typos were not sufficient
> reason to tamper with history.
>
> However, committers sometimes forget critical information, such as the bug
> # associated with a commit, or other information critical to a useful audit
> trail.
>
> To avoid losing history, and yet allow for such critical information, our
> work-around is to allow changes to the svn:log property, but *only* allow
> appending to existing contents. Once we put that in, people stopped
> complaining.
>
> We don't allow users to change any other revprops.
>
> Eric.
>
> On Fri, Feb 26, 2016 at 7:40 AM, Alfred von Campe 
> wrote:
>
>> Is modifying the unversioned svn:log property considered bad practice?
>> We’re about to upgrade to a new Subversion server at work, and the central
>> group that manages that server will no longer allow modifications to
>> unversioned properties.  Their main reason is so that third party tools
>> like Jira and Crucible, that have daemons that scan check-in comments for
>> keywords and index the results, don’t have to be re-run again to re-index
>> updated commits.  They are recommending creating a property on all the
>> files that were affected in a commit (the name/value of the property is not
>> important), and then committing that change with the “correct” check-in
>> comment.  I can see their point, but sometimes you just want to correct a
>> minor typo in a commit log.
>>
>> I’m just wondering what collective wisdom of this group is in regards to
>> updating the svn:log property (or other unversioned properties)?
>>
>> Thanks,
>> Alfred
>>
>>
>
>

Re: Modifying svn:log property: good or bad?

[Alfred von Campe]

Eric:

Would you mind sharing your (redacted if necessary) commit hook that enforces 
the policies you mentioned?

Alfred

> On Feb 26, 2016, at 14:01, Eric Johnson  wrote:
> 
> We definitely enforce restrictions. We also log all revprop changes.
> 
> Keep in mind that this information is key to establishing a historical record 
> of what happened with your source code. If you're lawyers haven't advised you 
> already, you might want to consider what happens if you ever get hauled into 
> court, and need to testify about the quality of the historical information in 
> your Subversion repositories. You want to keep the list of people that can 
> change the revprops (and the revisions themselves) to an absolute minimum.
> 
> Eric.
> 
> 
> On Fri, Feb 26, 2016 at 10:03 AM, Alfred von Campe  > wrote:
> Eric:
> 
> Thanks for the feedback.  Do you enforce just appending to the svn:log 
> property or is that just the policy and everyone follows it?  Same question 
> for modifying the other recprops: do you enforce it or is it just policy?
> 
> Alfred
> 
>> On Feb 26, 2016, at 12:42, Eric Johnson > > wrote:
>> 
>> We looked at this problem, and decided that typos were not sufficient reason 
>> to tamper with history.
>> 
>> However, committers sometimes forget critical information, such as the bug # 
>> associated with a commit, or other information critical to a useful audit 
>> trail.
>> 
>> To avoid losing history, and yet allow for such critical information, our 
>> work-around is to allow changes to the svn:log property, but only allow 
>> appending to existing contents. Once we put that in, people stopped 
>> complaining.
>> 
>> We don't allow users to change any other revprops.
>> 
>> Eric.
>> 
>> On Fri, Feb 26, 2016 at 7:40 AM, Alfred von Campe > > wrote:
>> Is modifying the unversioned svn:log property considered bad practice?  
>> We’re about to upgrade to a new Subversion server at work, and the central 
>> group that manages that server will no longer allow modifications to 
>> unversioned properties.  Their main reason is so that third party tools like 
>> Jira and Crucible, that have daemons that scan check-in comments for 
>> keywords and index the results, don’t have to be re-run again to re-index 
>> updated commits.  They are recommending creating a property on all the files 
>> that were affected in a commit (the name/value of the property is not 
>> important), and then committing that change with the “correct” check-in 
>> comment.  I can see their point, but sometimes you just want to correct a 
>> minor typo in a commit log.
>> 
>> I’m just wondering what collective wisdom of this group is in regards to 
>> updating the svn:log property (or other unversioned properties)?
>> 
>> Thanks,
>> Alfred
>> 
>> 
> 
> 

Re: Modifying svn:log property: good or bad?

[Eric Johnson]

Sorry, but it looks like our pre-revprop-change script is just a little to
specific to my company, and I don't see a quick way to extract out a quick
working version.

Eric.

On Fri, Feb 26, 2016 at 11:22 AM, Alfred von Campe 
wrote:

> Eric:
>
> Would you mind sharing your (redacted if necessary) commit hook that
> enforces the policies you mentioned?
>
> Alfred
>
> On Feb 26, 2016, at 14:01, Eric Johnson  wrote:
>
> We definitely enforce restrictions. We also log all revprop changes.
>
> Keep in mind that this information is key to establishing a historical
> record of what happened with your source code. If you're lawyers haven't
> advised you already, you might want to consider what happens if you ever
> get hauled into court, and need to testify about the quality of the
> historical information in your Subversion repositories. You want to keep
> the list of people that can change the revprops (and the revisions
> themselves) to an absolute minimum.
>
> Eric.
>
>
> On Fri, Feb 26, 2016 at 10:03 AM, Alfred von Campe 
> wrote:
>
>> Eric:
>>
>> Thanks for the feedback.  Do you enforce just appending to the svn:log
>> property or is that just the policy and everyone follows it?  Same question
>> for modifying the other recprops: do you enforce it or is it just policy?
>>
>> Alfred
>>
>> On Feb 26, 2016, at 12:42, Eric Johnson  wrote:
>>
>> We looked at this problem, and decided that typos were not sufficient
>> reason to tamper with history.
>>
>> However, committers sometimes forget critical information, such as the
>> bug # associated with a commit, or other information critical to a useful
>> audit trail.
>>
>> To avoid losing history, and yet allow for such critical information, our
>> work-around is to allow changes to the svn:log property, but *only* allow
>> appending to existing contents. Once we put that in, people stopped
>> complaining.
>>
>> We don't allow users to change any other revprops.
>>
>> Eric.
>>
>> On Fri, Feb 26, 2016 at 7:40 AM, Alfred von Campe 
>> wrote:
>>
>>> Is modifying the unversioned svn:log property considered bad practice?
>>> We’re about to upgrade to a new Subversion server at work, and the central
>>> group that manages that server will no longer allow modifications to
>>> unversioned properties.  Their main reason is so that third party tools
>>> like Jira and Crucible, that have daemons that scan check-in comments for
>>> keywords and index the results, don’t have to be re-run again to re-index
>>> updated commits.  They are recommending creating a property on all the
>>> files that were affected in a commit (the name/value of the property is not
>>> important), and then committing that change with the “correct” check-in
>>> comment.  I can see their point, but sometimes you just want to correct a
>>> minor typo in a commit log.
>>>
>>> I’m just wondering what collective wisdom of this group is in regards to
>>> updating the svn:log property (or other unversioned properties)?
>>>
>>> Thanks,
>>> Alfred
>>>
>>>
>>
>>
>
>