>> I can only think of one option at this moment that is to move the
svn:mergeinfo property to somewhere else, where everyone could commit the
changes and not just the committer having framework rights.

This is not possible AFAIK.
As it is Subversion standard and we are using it.

--
Ashish

On Thu, May 21, 2009 at 2:55 PM, Ashish Vijaywargiya <
ashish.vijaywarg...@hotwaxmedia.com> wrote:

> AFAIK the use of maintaining the svn:mergeinfo is encouraged by subversion
> project after release 1.5.
> This is actually required when you maintain such release branch and that
> takes update from trunk.
> (As I remembered that something similar is commented by Jacuqes in past,
> But I could be wrong.)
>
> Sharing the link that can provide more insight:
> http://subversion.tigris.org/merge-tracking/func-spec.html
> Although I haven't read full details but certainly will read it in a day or
> so.
>
> Let see what Jacques has to say about it.
>
> --
> Ashish
>
>
> Scott Gray wrote:
>
>> Sorry if this is an svn noob question, but what's so great about this
>> mergeinfo file that it's worth the extra effort anyway?
>>
>> Thanks
>> Scott
>>
>> On 21/05/2009, at 9:05 PM, Ashish Vijaywargiya wrote:
>>
>>  Hello Jacques,
>>>
>>> As we all know that we are maintaining the details of revision (trunk
>>> revision details that we apply to RB9.04) in the svn:mergeinfo file.
>>> But certainly we(Me, Vikas and few others don't have framework and OFBiz
>>> root files / folder write access) don't have commit right for that file so
>>> most of the time we leave that file as it is.
>>> And wait for someone like you to commit the changes later on.
>>>
>>> What can be the better solution to handle this ?
>>> Is it good that we commit the code in release branch and explicitly
>>> inform to commit the changes in svn:mergeinfo file ?
>>>
>>> Please let me know your thoughts on this, as your comment on this will
>>> help us not to miss any version info from svn:mergeinfo file after
>>> committing the code.
>>> Thanks !
>>>
>>> --
>>> Ashish
>>>
>>>
>>

Reply via email to