Re: svn commit: r21294 - in branches/ebcdic/v5r4/1.4.x: . build build/generator build/win32 contrib/client-side packages/rpm/redhat-8+ packages/rpm/rhel-3 packages/rpm/rhel-4 packages/windows-innosetup subversion subversion/bindings/swig subversion/bindings/swig/include subversion/bindings/swig/ruby/svn subversion/bindings/swig/ruby/test subversion/include subversion/libsvn_client subversion/libsvn_fs subversion/libsvn_fs_base subversion/libsvn_fs_fs subversion/libsvn_ra subversion/libsvn_ra_dav subversion/libsvn_ra_local subversion/libsvn_ra_serf subversion/libsvn_ra_svn subversion/libsvn_repos subversion/libsvn_subr subversion/libsvn_wc subversion/mod_dav_svn subversion/po subversion/svn subversion/svnadmin subversion/svnserve subversion/svnsync subversion/tests/cmdline subversion/tests/cmdline/svntest tools/hook-scripts/mailer tools/po

[Kamesh Jayachandran <ka...@collab.net>]

pburba@tigris.org wrote:
> Author: pburba
> Date: Mon Aug 28 06:57:49 2006
> New Revision: 21294
>
> Log:
> Merge r20780:21228 from branches/1.4.x to branches/ebcdic/V5R4/1.4.x.
>
>   
Should we not use svnmerge.py to record merges?

With regards
Kamesh Jayachandran

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

Re: svnmerge.py Policy (Was: Re: svn commit: r21294 - in branches/ebcdic/v5r4/1.4.x...)

[Daniel Rall <dl...@collab.net>]

On Mon, 28 Aug 2006, Justin Erenkrantz wrote:

> On 8/28/06, Paul Burba <pa...@softlanding.com> wrote:
> >I looked at using svnmerge.py for this merge, recalling a few posts
> >mentioning it.  But after finding little in the way of guidance on how to
> >use it on an existing branch that's been merged into repeatedly already, I
> >turned my attention to other things.  I did this somewhat out of
> >frustration but mostly because I was unaware it was required...
> 
> As I've said before, those people who want us to use svnmerge.py
> everywhere need to commit some instructions somewhere into HACKING.
> Ideally, example snippets should also be included in STATUS or
> whatever.  But, forcing people to play hunt the wumpus to merge is
> silly.  -- justin

Why not require its use only for release branches?  It's already setup
for all such branches...

Re: svnmerge.py Policy (Was: Re: svn commit: r21294 - in branches/ebcdic/v5r4/1.4.x...)

[Justin Erenkrantz <ju...@erenkrantz.com>]

On 8/28/06, Paul Burba <pa...@softlanding.com> wrote:
> I looked at using svnmerge.py for this merge, recalling a few posts
> mentioning it.  But after finding little in the way of guidance on how to
> use it on an existing branch that's been merged into repeatedly already, I
> turned my attention to other things.  I did this somewhat out of
> frustration but mostly because I was unaware it was required...

As I've said before, those people who want us to use svnmerge.py
everywhere need to commit some instructions somewhere into HACKING.
Ideally, example snippets should also be included in STATUS or
whatever.  But, forcing people to play hunt the wumpus to merge is
silly.  -- justin

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

svnmerge.py Policy (Was: Re: svn commit: r21294 - in branches/ebcdic/v5r4/1.4.x...)

[Paul Burba <pa...@softlanding.com>]

"C. Michael Pilato" <cm...@collab.net> wrote on 08/28/2006 02:04:33 PM:

> Kamesh Jayachandran wrote:
> > pburba@tigris.org wrote:
> >> Author: pburba
> >> Date: Mon Aug 28 06:57:49 2006
> >> New Revision: 21294
> >>
> >> Log:
> >> Merge r20780:21228 from branches/1.4.x to branches/ebcdic/V5R4/1.4.x.
> >>
> >> 
> > Should we not use svnmerge.py to record merges?

Hi All,

I looked at using svnmerge.py for this merge, recalling a few posts 
mentioning it.  But after finding little in the way of guidance on how to 
use it on an existing branch that's been merged into repeatedly already, I 
turned my attention to other things.  I did this somewhat out of 
frustration but mostly because I was unaware it was required...
 
> I believe this is (and should be) a policy applied at a given branch
> owner's discretion.

...So what is our policy exactly?  There is no mention of it in HACKING, 
should there be?

Paul B.
 
> -- 
> C. Michael Pilato <cm...@collab.net>
> CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
> 
> [attachment "signature.asc" deleted by Paul Burba/SoftLanding Systems]


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

Re: svn commit: r21294 - in branches/ebcdic/v5r4/1.4.x: . build build/generator build/win32 contrib/client-side packages/rpm/redhat-8+ packages/rpm/rhel-3 packages/rpm/rhel-4 packages/windows-innosetup subversion subversion/bindings/swig subversion/bindings/swig/include subversion/bindings/swig/ruby/svn subversion/bindings/swig/ruby/test subversion/include subversion/libsvn_client subversion/libsvn_fs subversion/libsvn_fs_base subversion/libsvn_fs_fs subversion/libsvn_ra subversion/libsvn_ra_dav subversion/libsvn_ra_local subversion/libsvn_ra_serf subversion/libsvn_ra_svn subversion/libsvn_repos subversion/libsvn_subr subversion/libsvn_wc subversion/mod_dav_svn subversion/po subversion/svn subversion/svnadmin subversion/svnserve subversion/svnsync subversion/tests/cmdline subversion/tests/cmdline/svntest tools/hook-scripts/mailer tools/po

["C. Michael Pilato" <cm...@collab.net>]

Kamesh Jayachandran wrote:
> pburba@tigris.org wrote:
>> Author: pburba
>> Date: Mon Aug 28 06:57:49 2006
>> New Revision: 21294
>>
>> Log:
>> Merge r20780:21228 from branches/1.4.x to branches/ebcdic/V5R4/1.4.x.
>>
>>   
> Should we not use svnmerge.py to record merges?

I believe this is (and should be) a policy applied at a given branch
owner's discretion.

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand