On Sat, Oct 28, 2017 at 2:16 PM, Johan Corveleyn <jcor...@gmail.com> wrote:
> On Fri, Oct 27, 2017 at 9:36 PM, Dan Ellis <danelli...@gmail.com> wrote:
> > On Fri, Oct 27, 2017 at 12:06 AM, Johan Corveleyn <jcor...@gmail.com>
> wrote:
> >>
> >> On T
local repo?
Thanks!
On Fri, Oct 27, 2017 at 12:06 AM, Johan Corveleyn <jcor...@gmail.com> wrote:
> On Thu, Oct 26, 2017 at 11:50 PM, Dan Ellis <danelli...@gmail.com> wrote:
> >
> > Hi,
> >
> > I brought this up back in 2014 (https://svn.haxx.se/users/
&g
Hi,
I brought this up back in 2014 (
https://svn.haxx.se/users/archive-2014-05/0115.shtml). I managed to work
around it but just ended up running into it again. I'm running SVN 1.8.13.
C:\Project_files\wc1>svn rename C:\project_files\wc1\foo.c bar.c
svn: E155004: Run 'svn cleanup' to remove
On Thu, Apr 30, 2015 at 8:02 PM, Daniel Shahaf d...@daniel.shahaf.name
wrote:
Dan Ellis wrote on Thu, Apr 30, 2015 at 14:52:23 -0700:
Here's a snippet of the running scenario that can NOT reproduce the issue
in a new repo:
In the situation that reproduces the problem:
- What happens when
OK, so it gets stranger...
I admit I changed the property names a bit to simplify them. When I ran
the simplified names, it does work.
Here's the exact example that does not work:
c:\Project_files\sandbox_v2svn pl -v A.txt
Properties on 'A.txt':
pebls:plcm
On Thu, Apr 30, 2015 at 2:30 PM, Andrew Reedick jreed...@incomm.com wrote:
From: Dan Ellis [mailto:danelli...@gmail.com]
**Brane asked: There's no REN.txt in your example.
**Anyway, please tell us which version of the client you're using (svn
--version) and where it came from.
I
On Wed, Apr 29, 2015 at 4:01 PM, Daniel Shahaf d...@daniel.shahaf.name
wrote:
Dan Ellis wrote on Wed, Apr 29, 2015 at 15:43:00 -0700:
Hi,
We use some custom properties for tracking (e.g. my_prop:trace_to
req_12345) and have noticed that svn renames do not copy these across the
delete
8cd8818d6b4f5edcb8b6e25cdf471af62bca403c
c:\Project_files\sandbox_v2svn rename A.txt AA.txt
A AA.txt
D A.txt
c:\Project_files\sandbox_v2svn pl -v AA.txt
c:\Project_files\sandbox_v2svn pl -v REN.txt
On Wed, Apr 29, 2015 at 4:13 PM, Dan Ellis danelli
Hi,
We use some custom properties for tracking (e.g. my_prop:trace_to
req_12345) and have noticed that svn renames do not copy these across the
delete/add operation. I've tried searching the archives to see if I could
find a rationale as to why, but haven't come across any.
I'm guessing this
On Fri, Aug 29, 2014 at 2:14 AM, Stefan Sperling s...@elego.de wrote:
On Thu, Aug 28, 2014 at 02:55:57PM -0700, Dan Ellis wrote:
It sounds like if you'd be in less trouble if you could 'revert'
individual
property changes to the working copy's BASE state independently
Hi,
This has been brought up before but in a different context (
http://mail-archives.apache.org/mod_mbox/subversion-dev/201311.mbox/%3c20131107155018.gg10...@ted.stsp.name%3E
)
We maintain some vendor-like code on some branches that we periodically
want to merge into our development branch.
On Thu, Aug 28, 2014 at 2:27 PM, Stefan Sperling s...@elego.de wrote:
On Thu, Aug 28, 2014 at 02:03:59PM -0700, Dan Ellis wrote:
Hi,
Can anyone talk about the robustness of a diff/patch solution to merging
on
text contents?
It would work fine, except for tree changes (though 'svn merge
I don't think this is a merge problem as much as a conflict resolution
problem. Perhaps efforts would be a better invested in trying to improve
the property conflict resolution mechanisms of 'svn resolve' to make
your workflow easier?
It sounds like if you'd be in less trouble if you could
Hi,
In a recent thread I've been trying to figure out the best way to deal with
case sensitivity issues (in particular, finding out the clashing case
sensitive path). It doesn't appear that I'll be able to solve that one
readily, so I plan to convert all our existing mixed case entries to lower
The pre-commit hook script is only called if Subversion's internal checks
already passed; if the internal checks fail, there's no reason to call the
pre-commit hook script since the commit will fail regardless of the hook
script's outcome.
The internal check that failed in this case was
--parents is implemented by the client. The client first builds up a
transaction on the server and then tells the server to attempt to commit
the transaction. Without --parents the copy fails while building the
transaction so no attempt is made to commit the transaction. With
--parents
Hi,
I'm wondering if I'm getting an incorrect error message...
I'm attempting to copy a file from a working copy to the server, but using
an incorrect case for one of the folders in the path. The paths all exist
and everything works fine using correct case. In the example below, FOO
exists on
, delete or rename the directory from that
machine. (Don't forget that you have to escape the backslash with a
second backslash for the shell.)
Tobias
On 07.05.2014, at 01:25, Dan Ellis wrote:
Hi,
I pulled a silly mistake just now... I accidentally let my windows
backslash enter
\sandbox_v2\.txt
A C:\project_files\sandbox_v2\.txt
I may try upgrading to 1.8.8 if you think there have been any changes since
1.8.5 in this area.
Thanks,
Dan
On Tue, May 13, 2014 at 9:42 AM, Ben Reser b...@reser.org wrote:
On 5/12/14, 2:36 PM, Dan Ellis wrote:
I'm trying
On Tue, May 13, 2014 at 10:16 AM, Ben Reser b...@reser.org wrote:
On 5/12/14, 2:49 PM, Dan Ellis wrote:
When performing an svn info on a local working copy, I can see the file's
checksum (sha-1 specifically), but this doesn't work on repositories. It
would
be really nice and save some
Hi,
I'm trying to diff the contents between of a local working copy file to a
file in the repository (I really just need a yes/no answer). This file
happens to be identical in content, but they do not share the same ancestry
(unrelated nodes).
When I do a diff with no --summarize option, I get
The depth parameter is used in many places, not just in svn list;
whatever enhancement you come up with must at least fit the other uses.
Depth was invented to describe sparse working copies, and was only later
adapted to other commands. For sparse working copies, depth=dirs probably
doesn't
Thank you very much for the speedy change!
On Fri, May 2, 2014 at 10:54 PM, Ben Reser b...@reser.org wrote:
On 5/2/14, 3:24 PM, Dan Ellis wrote:
svnmucc currently only supports linefeed (LF, \n) line endings and
complains
about window's style carriage return, linefeed (CRLFs, \r\n
Hi,
The svn command line list command currently accepts --depth arguments of
files, infinity, and immediates (and empty, but that is really a no-op).
I'm in need of being able to list directory entries only in a repository,
but I'm not sure there is any good way to accomplish that as-is. I've
Hi,
svnmucc currently only supports linefeed (LF, \n) line endings and
complains about window's style carriage return, linefeed (CRLFs, \r\n) with:
Error: svnmucc: E125005: Cannot accept non-LF line endings in 'svn:log'
property
This is inconsistent with the svn command line that allows both but
25 matches
Mail list logo
