Re: [PATCH] Honor SVN auto-props (solves issue #186)

Queued, thanks.

On May 24, 2012, at 4:14 PM, Ronny Voelker wrote:

> # HG changeset patch
> # User Ronny Voelker <ronny.voelker@...>
> # Date 1325429955 -3600
> # Node ID 772280aed7513b672aa8ba060750f52518e1b20e
> # Parent  312f36a425f01328c9f36b831019c30b6f4957fc
> Honor SVN auto-props (solves issue #186)
> 
> The auto-props are read from the users subversion configuration file
> (~/.subversion/config on posix). System-wide configuration files are not
> taken into account.
> 
> The implementation completely bypasses the subversion bindings,
> because the current bindings provide little support for this functionality.
> 
> diff -r 312f36a425f0 -r 772280aed751 hgsubversion/pushmod.py
> --- a/hgsubversion/pushmod.py	Thu May 17 14:15:14 2012 -0700
> +++ b/hgsubversion/pushmod.py	Sun Jan 01 15:59:15 2012 +0100
>  <at>  <at>  -133,6 +133,10  <at>  <at> 
>                     # this kind of renames: a -> b, b -> c
>                     copies[file] = renamed[0]
>                     base_data = parent[renamed[0]].data()
> +                else:
> +                    autoprops = svn.autoprops_config.properties(file) 
> +                    if autoprops:
> +                        props.setdefault(file, {}).update(autoprops)
> 

#349 Rebase uncommitted changes after pushing

https://bitbucket.org/durin42/hgsubversion/issue/349/rebase-uncommitted-changes-after-pushing
was closed as wontfix because "feels really dangerous, since pushing
has an implicit rebase".

Your rebasing back onto the same changesets IIUC, just with the
metadata rewritten by subversion. So how is this really dangerous?

--

-- 
You received this message because you are subscribed to the Google Groups "hgsubversion" group.
To post to this group, send email to hgsubversion@...
To unsubscribe from this group, send email to hgsubversion+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hgsubversion?hl=en.

Re: #349 Rebase uncommitted changes after pushing

On 6/2/2012 1:26 PM, gidyn wrote:
> https://bitbucket.org/durin42/hgsubversion/issue/349/rebase-uncommitted-changes-after-pushing
> was closed as wontfix because "feels really dangerous, since pushing
> has an implicit rebase".
>
> Your rebasing back onto the same changesets IIUC, just with the
> metadata rewritten by subversion. So how is this really dangerous?
>

It's not that simple. On a busy repository (or just with bad luck), 
you'll also get any changes that came in since your last pull, 
potentially including ones that were going in during your push. There's 
no way to be sure that the commits coming back from svn would be cleanly 
reabased.

--

-- 
You received this message because you are subscribed to the Google Groups "hgsubversion" group.
To post to this group, send email to hgsubversion@...
To unsubscribe from this group, send email to hgsubversion+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hgsubversion?hl=en.

Re: #349 Rebase uncommitted changes after pushing

Re: #349 Rebase uncommitted changes after pushing

On Jun 4, 2012, at 1:15 AM, gsireling@... wrote:

> On Sunday, 3 June 2012 23:26:28 UTC+3, Augie wrote:
>> 
>> On 6/2/2012 1:26 PM, gidyn wrote: 
>>> 
>>
https://bitbucket.org/durin42/hgsubversion/issue/349/rebase-uncommitted-changes-after-pushing 
>>> was closed as wontfix because "feels really dangerous, since pushing 
>>> has an implicit rebase". 
>>> 
>>> Your rebasing back onto the same changesets IIUC, just with the 
>>> metadata rewritten by subversion. So how is this really dangerous? 
>>> 
>> 
>> It's not that simple. On a busy repository (or just with bad luck), 
>> you'll also get any changes that came in since your last pull, 
>> potentially including ones that were going in during your push. There's 
>> no way to be sure that the commits coming back from svn would be cleanly 
>> reabased.
>> 
> 
> Don't you get a new head when pulling divergent changesets from the remote 
> repository? Confused. 

WIth hgsubversion it's not divergent, because Subversion has a rebase step built into its commit
finalization process.

> 
> -- 
> You received this message because you are subscribed to the Google Groups "hgsubversion" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/hgsubversion/-/w5UJ8eHMg60J.
> To post to this group, send email to hgsubversion@...
> To unsubscribe from this group, send email to hgsubversion+unsubscribe@...
> For more options, visit this group at http://groups.google.com/group/hgsubversion?hl=en.
> 

--

-- 
You received this message because you are subscribed to the Google Groups "hgsubversion" group.
To post to this group, send email to hgsubversion@...
To unsubscribe from this group, send email to hgsubversion+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hgsubversion?hl=en.

Re: #349 Rebase uncommitted changes after pushing

Re: #349 Rebase uncommitted changes after pushing

On Jun 4, 2012, at 7:37 AM, gsireling@... wrote:

> On Monday, 4 June 2012 15:23:18 UTC+3, Augie wrote:
>> 
>> 
>> On Jun 4, 2012, at 1:15 AM,wrote: 
>> 
>>> On Sunday, 3 June 2012 23:26:28 UTC+3, Augie wrote: 
>>> 
>>> Don't you get a new head when pulling divergent changesets from the 
>> remote 
>>> repository? Confused. 
>> 
>> WIth hgsubversion it's not divergent, because Subversion has a rebase step 
>> built into its commit finalization process.
>> 
> 
> How does this differ from the pull behaviour described in the 
> documentation, where "If there are new revisions, and you have new 
> revisions in your local hg repository, this will create a new head"? Is 
> there a difference here between pulling and pushing? 

Yes - pushing includes a rebase step to conform to Subversion's requirements. You don't get the exact same
change back, and it might not be in the same place in the DAG of history - it could end up as a grandchild of its
former parent (for example).

> 
> -- 
> You received this message because you are subscribed to the Google Groups "hgsubversion" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/hgsubversion/-/19fPswqGsp4J.
> To post to this group, send email to hgsubversion@...
> To unsubscribe from this group, send email to hgsubversion+unsubscribe@...
> For more options, visit this group at http://groups.google.com/group/hgsubversion?hl=en.
> 

--

-- 
You received this message because you are subscribed to the Google Groups "hgsubversion" group.
To post to this group, send email to hgsubversion@...
To unsubscribe from this group, send email to hgsubversion+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hgsubversion?hl=en.

Re: #349 Rebase uncommitted changes after pushing

On Monday, 4 June 2012 15:40:00 UTC+3, Augie wrote:

On Jun 4, 2012, at 7:37 AM, gidyn wrote:

> On Monday, 4 June 2012 15:23:18 UTC+3, Augie wrote:
>>
>>
>> On Jun 4, 2012, at 1:15 AM,wrote:
>>
>>> On Sunday, 3 June 2012 23:26:28 UTC+3, Augie wrote:
>>>
>>> Don't you get a new head when pulling divergent changesets from the
>> remote
>>> repository? Confused.
>>
>> WIth hgsubversion it's not divergent, because Subversion has a rebase step
>> built into its commit finalization process.
>>
>
> How does this differ from the pull behaviour described in the
> documentation, where "If there are new revisions, and you have new
> revisions in your local hg repository, this will create a new head"? Is
> there a difference here between pulling and pushing?

Yes - pushing includes a rebase step to conform to Subversion's requirements. You don't get the exact same change back, and it might not be in the same place in the DAG of history - it could end up as a grandchild of its former parent (for example).

Ah. Perhaps the documentation could mention this, it isn't obvious

So the working directory's parent will be silently rebased on commit (as required by subversion), but it's too dangerous to rebase the working directory with it?

--
You received this message because you are subscribed to the Google Groups "hgsubversion" group.
To view this discussion on the web visit https://groups.google.com/d/msg/hgsubversion/-/8BlX5okOUi8J.
To post to this group, send email to hgsubversion-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to hgsubversion+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/hgsubversion?hl=en.

Re: #349 Rebase uncommitted changes after pushing

On Jun 4, 2012, at 7:45 AM, gsireling@... wrote:

> On Monday, 4 June 2012 15:40:00 UTC+3, Augie wrote:
>> 
>> 
>> On Jun 4, 2012, at 7:37 AM, gidyn wrote: 
>> 
>>> On Monday, 4 June 2012 15:23:18 UTC+3, Augie wrote: 
>>>> 
>>>> 
>>>> On Jun 4, 2012, at 1:15 AM,wrote: 
>>>> 
>>>>> On Sunday, 3 June 2012 23:26:28 UTC+3, Augie wrote: 
>>>>> 
>>>>> Don't you get a new head when pulling divergent changesets from the 
>>>> remote 
>>>>> repository? Confused. 
>>>> 
>>>> WIth hgsubversion it's not divergent, because Subversion has a rebase 
>> step 
>>>> built into its commit finalization process. 
>>>> 
>>> 
>>> How does this differ from the pull behaviour described in the 
>>> documentation, where "If there are new revisions, and you have new 
>>> revisions in your local hg repository, this will create a new head"? Is 
>>> there a difference here between pulling and pushing? 
>> 
>> Yes - pushing includes a rebase step to conform to Subversion's 
>> requirements. You don't get the exact same change back, and it might not be 
>> in the same place in the DAG of history - it could end up as a grandchild 
>> of its former parent (for example). 
>> 
> 
> Ah. Perhaps the documentation could mention this, it isn't obvious 
> 
> So the working directory's parent will be silently rebased on commit (as 
> required by subversion), but it's too dangerous to rebase the working 
> directory with it?

Subversion makes guarantees about the nature of that rebase step that makes it safe for the just-pushed
commit. There'd be no way to have the same safety surrounding uncommitted changes in the working directory.

> 
> -- 
> You received this message because you are subscribed to the Google Groups "hgsubversion" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/hgsubversion/-/8BlX5okOUi8J.
> To post to this group, send email to hgsubversion@...
> To unsubscribe from this group, send email to hgsubversion+unsubscribe@...
> For more options, visit this group at http://groups.google.com/group/hgsubversion?hl=en.
> 

--

-- 
You received this message because you are subscribed to the Google Groups "hgsubversion" group.
To post to this group, send email to hgsubversion@...
To unsubscribe from this group, send email to hgsubversion+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hgsubversion?hl=en.

Re: #349 Rebase uncommitted changes after pushing

On 4 Jun 2012, at 14:45, gsireling@... wrote:

> On Monday, 4 June 2012 15:40:00 UTC+3, Augie wrote:
>> 
>> 
>> On Jun 4, 2012, at 7:37 AM, gidyn wrote: 
>> 
>>> On Monday, 4 June 2012 15:23:18 UTC+3, Augie wrote: 
>>>> 
>>>> 
>>>> On Jun 4, 2012, at 1:15 AM,wrote: 
>>>> 
>>>>> On Sunday, 3 June 2012 23:26:28 UTC+3, Augie wrote: 
>>>>> 
>>>>> Don't you get a new head when pulling divergent changesets from the 
>>>>> remote repository? Confused. 
>>>> 
>>>> WIth hgsubversion it's not divergent, because Subversion has a rebase 
>>>> step built into its commit finalization process. 
>>>> 
>>> 
>>> How does this differ from the pull behaviour described in the 
>>> documentation, where "If there are new revisions, and you have new 
>>> revisions in your local hg repository, this will create a new head"? Is 
>>> there a difference here between pulling and pushing? 
>> 
>> Yes - pushing includes a rebase step to conform to Subversion's 
>> requirements. You don't get the exact same change back, and it might not be 
>> in the same place in the DAG of history - it could end up as a grandchild 
>> of its former parent (for example). 
>> 
> 
> Ah. Perhaps the documentation could mention this, it isn't obvious 

Actually, it does: see 'hg help subversion'. Perhaps not the most obvious location, but better than
nothing 

--

Dan Villiom Podlaski Christiansen
danchr@... (mail & IM)