On Friday 30 May 2008 10:51:50 am John Hunter wrote:
> On Fri, May 30, 2008 at 9:12 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> > FYI: I have a little time today to do some documentation work myself
> > today. I've been doing some minor edits (mostly formatting things) on the
> > developer
On Fri, May 30, 2008 at 9:12 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> FYI: I have a little time today to do some documentation work myself today.
> I've been doing some minor edits (mostly formatting things) on the
> developer docs, and then was going to hit up the user docs. Does tha
Darren Dale wrote:
> On Thursday 29 May 2008 10:59:40 am Michael Droettboom wrote:
>
>> Darren Dale wrote:
>>
>>> I'm sorry, I just don't understand how to use this.
>>>
>
> And I'm also sorry for my mild panic attack yesterday. I had way too many
> things coming at me all at once.
On Thursday 29 May 2008 10:59:40 am Michael Droettboom wrote:
> Darren Dale wrote:
> > I'm sorry, I just don't understand how to use this.
And I'm also sorry for my mild panic attack yesterday. I had way too many
things coming at me all at once. Things are back to normal today.
> I can do the me
Michael Droettboom wrote:
> John Hunter wrote:
>
>> On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <[EMAIL PROTECTED]>
>> wrote:
>>
>>
>>
>>> Minor point: On my machine at least, I don't have to manually clean up the
>>> conflict files -- they are removed for me on the next commit.
John Hunter wrote:
> On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>
>> Minor point: On my machine at least, I don't have to manually clean up the
>> conflict files -- they are removed for me on the next commit. Those files
>> are really just for reference. I
On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> Minor point: On my machine at least, I don't have to manually clean up the
> conflict files -- they are removed for me on the next commit. Those files
> are really just for reference. If you use a SVN frontend for d
John Hunter wrote:
> On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>
>> So, this is more the fault of operating procedure (choosing not to do the
>> numpy renaming on the branch, for instance, which in itself was not a bad
>> decision in isolation), than the to
Thanks Mike.
On Thursday 29 May 2008 10:59:40 am Michael Droettboom wrote:
> Darren Dale wrote:
> > On Thursday 29 May 2008 10:15:07 am John Hunter wrote:
> >> On Thu, May 29, 2008 at 9:11 AM, Darren Dale <[EMAIL PROTECTED]>
> >
> > wrote:
> >>> I dont understand. I thought the point of svnmerge.p
On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> So, this is more the fault of operating procedure (choosing not to do the
> numpy renaming on the branch, for instance, which in itself was not a bad
> decision in isolation), than the tool itself. Note that svnmerge
Darren Dale wrote:
> On Thursday 29 May 2008 10:15:07 am John Hunter wrote:
>
>> On Thu, May 29, 2008 at 9:11 AM, Darren Dale <[EMAIL PROTECTED]>
>>
> wrote:
>
>>> I dont understand. I thought the point of svnmerge.py was to sync the
>>> change, not to introduce conflicts. Is the proced
Darren Dale wrote:
> On Thursday 29 May 2008 10:04:34 am you wrote:
>
>> On Thu, May 29, 2008 at 9:01 AM, Darren Dale <[EMAIL PROTECTED]>
>>
> wrote:
>
>>> I am trying to merge a change to texmanager from the branch to the trunk,
>>> but something doesnt look right after I ran svnmerge.
On Thu, May 29, 2008 at 9:41 AM, Darren Dale <[EMAIL PROTECTED]> wrote:
> Thats not what I want, I only want to commit the changes I made to CHANGELOG
> and texmanager. I tried reverting the changes with svn revert, but now when I
> do a diff, I get:
>
> $ svn diff
>
> Property changes on: .
> ___
On Thursday 29 May 2008 10:15:07 am John Hunter wrote:
> On Thu, May 29, 2008 at 9:11 AM, Darren Dale <[EMAIL PROTECTED]>
wrote:
> > I dont understand. I thought the point of svnmerge.py was to sync the
> > change, not to introduce conflicts. Is the procedure you just outlined
> > the standard ope
On Thursday 29 May 2008 10:04:34 am you wrote:
> On Thu, May 29, 2008 at 9:01 AM, Darren Dale <[EMAIL PROTECTED]>
wrote:
> > I am trying to merge a change to texmanager from the branch to the trunk,
> > but something doesnt look right after I ran svnmerge.py. Look at all the
> > markup in the diff
On Thu, May 29, 2008 at 9:01 AM, Darren Dale <[EMAIL PROTECTED]> wrote:
> I am trying to merge a change to texmanager from the branch to the trunk, but
> something doesnt look right after I ran svnmerge.py. Look at all the markup
> in the diff, I can't commit this, can I?
No. The > +<<< .work
I am trying to merge a change to texmanager from the branch to the trunk, but
something doesnt look right after I ran svnmerge.py. Look at all the markup
in the diff, I can't commit this, can I?
$ svn diff
Property changes on: .
__
I haven't initialized it for that direction. In a lot of ways, svnmerge
is far less useful in that case because there are many more things going
on the trunk that you don't want in the branch than vice versa.
I think in this case, a vanilla 'svn merge' (i.e. not using svnmerge.py)
is probably
On Sat, May 17, 2008 at 4:40 PM, John Hunter <[EMAIL PROTECTED]> wrote:
> - Michael advises making the change on the branch and committing
>it. Make sure you svn upped on the trunk and have no local
>modifications, and then from the svn trunk do
ichael -- what if someone has
I have been as guilty as anyone at this, but I think it will be good
for us to be careful to keep the branch and trunk in sync vis-a-vis
bugfixes where it makes sense as much as is possible. To date, I have
been fixing them in one place or another and Michael has been doing a
good job merging thin
20 matches
Mail list logo
