Anton Shepelev wrote on Sat, 28 Mar 2020 00:41 +00:00:
> Daniel Shahaf:
> > Tilde is also special to some shells, at least in the sh/csh
> > «~username» syntax and in zsh's «foo~bar» syntax (also part of
> > EXTENDED_GLOB);
>
> That is why I proposed a double `~' -- not perfect, of course, but
> I
Daniel Shahaf:
> Here are our notes about this from back when the ^/ syntax was
> added:
>
> http://svn.apache.org/viewvc/subversion/trunk/notes/cli-repo-root-relative-support.txt?view=markup#l42
It takes care of cmd.exe, so ^^/ on Windows was a deliberate
tradeoff on your part.
> Tilde is also
Anton Shepelev wrote on Fri, 27 Mar 2020 23:40 +00:00:
> Daniel Shahaf:
> > but in any case, this sounds quite reasonable. How about
> > assigning it the syntax «^./» (caret, dot, slash)? That way we
> > only have one "special" leading character to worry about.
>
> That ^ character must be escap
Daniel Shahaf:
> > I had already written about an extension of the caret syntax
> > to take the current working directory into account, so that,
> > being in svn/trunk/project/xml/ , one does not have to type
> >
> > svn cp ^/trunk/project/xml/1.xml ^/trunk/project/xml/2.xml
> >
> > but can si
Anton Shepelev wrote on Fri, 27 Mar 2020 01:39 +0300:
> Daniel Shahaf:
>
> > Yes, this feature won't happen unless someone invests time in
> > making it happen -- but let's not discourage people from
> > discussing feature ideas even if they may not personally have
> > time to implement them. Disc
On Thu, Mar 26, 2020 at 10:36 PM Daniel Shahaf wrote:
>
> Stefan Sperling wrote on Thu, 26 Mar 2020 21:02 +00:00:
> > The ultimate goal here is to allow users to type less characters when
> > starting merges. Scripting tab-completion for SVN URL arguments into
> > your favourite shell would also b
Daniel Shahaf:
> Yes, this feature won't happen unless someone invests time in
> making it happen -- but let's not discourage people from
> discussing feature ideas even if they may not personally have
> time to implement them. Discussions are just as useful a
> contribution as patches.
It is tru
Stefan Sperling:
> It's not that simple, as the conflict resolver demonstates.
> You're not taking cases into account where multiple copies within
> a signle revision correspond to a single deletion.
>
> So if you want to handle that then you must either error out when
> the heuristic fails, or m
Stefan Sperling wrote on Thu, 26 Mar 2020 21:02 +00:00:
> The ultimate goal here is to allow users to type less characters when
> starting merges. Scripting tab-completion for SVN URL arguments into
> your favourite shell would also be a usable and effective solution.
What would the algorithm be?
Stefan Sperling wrote on Thu, 26 Mar 2020 22:02 +0100:
> On Thu, Mar 26, 2020 at 08:46:35PM +, Daniel Shahaf wrote:
> > Stefan Sperling wrote on Thu, 26 Mar 2020 10:45 +0100:
> > > Renames are modelled as copy+delete in SVN.
> >
> > They are, but we can behave differently depending on whet
Stefan Sperling wrote on Thu, 26 Mar 2020 11:15 +0100:
> On Thu, Mar 26, 2020 at 01:10:25AM +0300, Anton Shepelev wrote:
> > Daniel Shahaf:
> > > however, I don't think the lack of these distinctions is
> > > necessarily a blocker. It just means we need to be more careful
> > > about not writing
On Thu, Mar 26, 2020 at 08:46:35PM +, Daniel Shahaf wrote:
> Stefan Sperling wrote on Thu, 26 Mar 2020 10:45 +0100:
> > Renames are modelled as copy+delete in SVN.
>
> They are, but we can behave differently depending on whether or not the
> adding-with-history was accompanied by a deletion in
Stefan Sperling wrote on Thu, 26 Mar 2020 10:45 +0100:
> On Thu, Mar 26, 2020 at 01:10:25AM +0300, Anton Shepelev wrote:
> > Daniel Shahaf:
> > > However, I can also see circumstances in which this smartness
> > > could be counter-productive:
> > >
> > > 1. In repository restructurings, such as
On Thu, Mar 26, 2020 at 01:10:25AM +0300, Anton Shepelev wrote:
> Daniel Shahaf:
> > however, I don't think the lack of these distinctions is
> > necessarily a blocker. It just means we need to be more careful
> > about not writing automation that will help some cases and
> > backfire in others.
>
On Thu, Mar 26, 2020 at 01:10:25AM +0300, Anton Shepelev wrote:
> Daniel Shahaf:
> > However, I can also see circumstances in which this smartness
> > could be counter-productive:
> >
> > 1. In repository restructurings, such as running «svn merge» in a
> > working copy of ^/thebarproject/trunk af
Anton Shepelev wrote on Thu, 26 Mar 2020 01:10 +0300:
> Daniel Shahaf:
> > 2. We can't trace copies forward. If trunk had been renamed or
> > forked after the merge, a simplistic "Take the
> > copyfrom_path@copyfrom_rev, change the copyfrom_rev to 'HEAD',
> > and use that as the URL to merge from"
Daniel Shahaf:
> Stefan Sperling wrote on Wed, 25 Mar 2020 15:07 +0100:
> > On Wed, Mar 25, 2020 at 04:45:29PM +0300, Anton Shepelev wrote:
> > > Why does even the basic sync-merging require that the user
> > > specify the source URL, as in:
> > >
> > > svn merge ^/project/trunk
> > >
> > > I
Stefan Sperling wrote on Wed, 25 Mar 2020 15:07 +0100:
> On Wed, Mar 25, 2020 at 04:45:29PM +0300, Anton Shepelev wrote:
> > Hello, all
> >
> > Why does even the basic sync-merging require that the user
> > specify the source URL, as in:
> >
> > svn merge ^/project/trunk
> >
> > I think this r
On Wed, Mar 25, 2020 at 04:45:29PM +0300, Anton Shepelev wrote:
> Hello, all
>
> Why does even the basic sync-merging require that the user
> specify the source URL, as in:
>
> svn merge ^/project/trunk
>
> I think this requirement is redundant because SVN know
> exactly from which original or
19 matches
Mail list logo
