On Sat, Oct 28, 2017 at 2:16 PM, Johan Corveleyn wrote:
> On Fri, Oct 27, 2017 at 9:36 PM, Dan Ellis wrote:
> > On Fri, Oct 27, 2017 at 12:06 AM, Johan Corveleyn
> wrote:
> >>
> >> On Thu, Oct 26, 2017 at 11:50 PM, Dan Ellis
> wrote:
> >> >
>
local repo?
Thanks!
On Fri, Oct 27, 2017 at 12:06 AM, Johan Corveleyn wrote:
> On Thu, Oct 26, 2017 at 11:50 PM, Dan Ellis wrote:
> >
> > Hi,
> >
> > I brought this up back in 2014 (https://svn.haxx.se/users/
> archive-2014-05/0115.shtml). I managed to work
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 lo
Hi,
I've noticed some differing behavior when using file externals and svn info
-r committed. I'm not sure what the expected behavior should be... hoping
to see what the masses think. I'm running svn 1.8.13 on Windows 7.
When I first create a file external and perform an update, the "svn info -
>
>
> On Thu, Apr 30, 2015 at 8:02 PM, Daniel Shahaf
> 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:
>>
>
OK,
On Thu, Apr 30, 2015 at 8:02 PM, Daniel Shahaf
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:
>
>
On Thu, Apr 30, 2015 at 2:30 PM, Andrew Reedick 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 w
>
>
>
> 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_v2>svn pl -v A.txt
>
> Properties on 'A.txt':
>
>
@4575
pebls:sha1
8cd8818d6b4f5edcb8b6e25cdf471af62bca403c
c:\Project_files\sandbox_v2>svn rename A.txt AA.txt
A AA.txt
D A.txt
c:\Project_files\sandbox_v2>svn pl -v AA.txt
c:\Project_files\sandbox_v2>svn pl -v REN.txt
On Wed, Apr 29, 2015 a
On Wed, Apr 29, 2015 at 4:01 PM, Daniel Shahaf
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 t
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 cou
On Fri, Aug 29, 2014 at 2:14 AM, Stefan Sperling 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
>
>
> 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 yo
On Thu, Aug 28, 2014 at 2:27 PM, Stefan Sperling 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 t
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. The
>
>
> --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
> --par
>
> 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 w
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
c
On Wed, May 21, 2014 at 3:22 AM, Ryan Schmidt <
subversion-2...@ryandesign.com> wrote:
>
> On May 20, 2014, at 17:02, Dan Ellis wrote:
>
> > 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
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
ess to a non-Windows machine, 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
On Tue, May 13, 2014 at 10:16 AM, Ben Reser 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
>> b
ize
D C:\project_files\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 wrote:
> On 5/12/14, 2:36 PM, Dan Ellis wrote:
> >
Hi,
Related to my other email regarding diffing a working copy file to a
potentially unrelated repository file; my real intent is to find out if two
files are different in content and really do not care about the actual
differences (the reason I want --summarize).
When performing an svn info on a
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 w
Hi,
I pulled a silly mistake just now... I accidentally let my windows
backslash enter into an http URL during an SVN copy operation.
copy --parents "C:\Project_files\sandbox\bar.c" "
http://svr/sandbox/A\B/bar1.c"; -m "bad commit"
It successfully committed.
svn update now returns the followin
>
>
>
> 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
On Sat, May 3, 2014 at 7:16 PM, Ryan Schmidt wrote:
>
> On May 3, 2014, at 20:13, Dan Ellis wrote:
>
> > 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
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
se
Thank you very much for the speedy change!
On Fri, May 2, 2014 at 10:54 PM, Ben Reser 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, line
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
31 matches
Mail list logo
