On Thu, May 30, 2024 at 5:09 PM Sands, Daniel N. via users <
users@subversion.apache.org> wrote:
>
> On 2024/02/15 17:42:59 "Sands, Daniel N. via users" wrote:
> > On Thu, 2024-02-15 at 08:55 -0500, Nico Kadel-Garcia wrote:
> > > [You don't often get email from nka...@gmail.com. Learn why this is
On 2024/02/15 17:42:59 "Sands, Daniel N. via users" wrote:
> On Thu, 2024-02-15 at 08:55 -0500, Nico Kadel-Garcia wrote:
> > [You don't often get email from nka...@gmail.com. Learn why this is
> > important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > On Wed, Feb 14, 2024 at 4:59 PM
On Thu, Feb 15, 2024 at 7:32 PM Sands, Daniel N. via users
wrote:
...
> On a further note, my real repo has 260 moves due to source tree
> restructuring. There were 290 deletions. The current move detection
> algorithm is an O(n^2) search to find all moves, where it ends up
> querying the SVN se
On Wed, Feb 14, 2024 at 11:00 PM Sands, Daniel N. via users
wrote:
>
> >
> Okay, I finally figured out how to trip up SVN:
>
>
>
>
> > > I built my own experiment which I'll try to reconstruct here:
> > > mkdir test
> > > mkdir test/foo
> > > mkdir test/foo/bar
> > > mkdir test/baz
> > > echo "a"
On Thu, 2024-02-15 at 08:55 -0500, Nico Kadel-Garcia wrote:
> [You don't often get email from nka...@gmail.com. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
>
> On Wed, Feb 14, 2024 at 4:59 PM Sands, Daniel N. via users
> wrote:
>
> > So lesson learned: Alway
On Wed, Feb 14, 2024 at 4:59 PM Sands, Daniel N. via users
wrote:
> So lesson learned: Always make a pristine copy of the trunk before
> making ANY changes, so that there is a revision to fall back on where
> the two branches exactly match.
That's what tags are for!
>
Okay, I finally figured out how to trip up SVN:
> > I built my own experiment which I'll try to reconstruct here:
> > mkdir test
> > mkdir test/foo
> > mkdir test/foo/bar
> > mkdir test/baz
> > echo "a" > test/foo/bar/example.c
> > svn import test svn+ssh://theserver/var/svn/playground/test
On Tue, 2024-02-13 at 16:50 -0700, Daniel Sands wrote:
> > Sorry for the late response, but I lack the time to dig deeper. It
> > should work as in the example (test) that Stanimir Stamenkov posted
> > earlier in this thread.
> >
> I don't fully follow that Derby example, but it does not look like
> Sorry for the late response, but I lack the time to dig deeper. It
> should work as in the example (test) that Stanimir Stamenkov posted
> earlier in this thread.
>
> Is your case the same as in the DERBY issue that Stanimir referenced
> [1]? Maybe you can narrow it down to a test with a reposit
On Mon, Feb 5, 2024 at 8:57 PM Sands, Daniel N. via users
wrote:
> > Oh yes, a lot has changed since 1.8 (which is EOL for a long time
> > already). Actually, the major improvement came client-side in version
> > 1.10, with the interactive tree conflict resolver [1]. This uses a
> > lot
> > of inf
>
> Oh yes, a lot has changed since 1.8 (which is EOL for a long time
> already). Actually, the major improvement came client-side in version
> 1.10, with the interactive tree conflict resolver [1]. This uses a
> lot
> of information from both working copy and repository to figure out
> what the
Fri, 2 Feb 2024, /Johan Corveleyn/:
On Fri, Feb 2, 2024 at 10:18 AM Stanimir Stamenkov via users wrote:
* Tree conflicts flagged by svn merge cannot be automatically resolved
yet. This will be addressed in a future release.
If I understand correctly, not much has changed related to merging
On Fri, Feb 2, 2024 at 10:18 AM Stanimir Stamenkov via users
wrote:
>
> Fri, 2 Feb 2024, /Sands, Daniel N./:
>
> >> As far as I'm aware this is all client-side behavior - nothing to do with
> >> the server. Resource move/rename
> >> has always been recorded as a _Delete_ of the original path and
Fri, 2 Feb 2024, /Sands, Daniel N./:
As far as I'm aware this is all client-side behavior - nothing to do with the
server. Resource move/rename
has always been recorded as a _Delete_ of the original path and a _Copy_ (Add)
from the previous path
revision. It could be I'm missing something here
fre 2 feb. 2024 kl. 06:52 skrev Sands, Daniel N. via users <
users@subversion.apache.org>:
> > As far as I'm aware this is all client-side behavior - nothing to do
> with the server. Resource move/rename
> > has always been recorded as a _Delete_ of the original path and a _Copy_
> (Add) from the
> As far as I'm aware this is all client-side behavior - nothing to do with the
> server. Resource move/rename
> has always been recorded as a _Delete_ of the original path and a _Copy_
> (Add) from the previous path
> revision. It could be I'm missing something here, also.
As of 1.8, it now kno
Tue, 30 Jan 2024, /Sands, Daniel N./:
So far I have not found a use case where moved file resolution in 1.8+
works as advertised on 1.7 servers. But more specifically, I have the
following case:
The trunk has a directory,
/foo/bar
In my local branch, I have relocated bar to
/baz/bar
Meanwh
So far I have not found a use case where moved file resolution in 1.8+ works as
advertised on 1.7 servers. But more specifically, I have the following case:
The trunk has a directory,
/foo/bar
In my local branch, I have relocated bar to
/baz/bar
Meanwhile, in the trunk, file /foo/bar/example.c
18 matches
Mail list logo
