It would have also been quite useful to get the filename of that file
that SVN tried to copy the temporary for. If it would have stated
"print_options.exe", we could have run a bit of testing just with that
one file to easier trace it down to an anti virus related problem (would
have been quite
I had a quick discussion on the IRC channel today about locking entire
directories in my repository. [1]
My company recently submitted version 4.0 of our application to Apple's
App Store. That submission was created from a tag which was itself
created from the 4.0 branch.
While we're waiting for
Hi,
thanks for the hints. I obviously mixed-up the thing with serf/neon.
Yes, the connection is via http.
Actually ur hints let me thinking it might be an access issue on my
machine and it turns out that when I disable my virus scanner,
everything works just fine (using avast! here).
The f
On 1/13/14, 1:32 PM, Stefan wrote:
> Sry, forgot the obvious most important info:
>
> Client is running 1.8.5
> Server is running Visual SVN 2.5.15 - based on SVN 1.7.13 - server is set-up
> to
> use neon.
FYI, the server doesn't use neon. Neon or Serf is only used on the client.
I'm guessing y
Sry, forgot the obvious most important info:
Client is running 1.8.5
Server is running Visual SVN 2.5.15 - based on SVN 1.7.13 - server is
set-up to use neon.
I traced the issue down to obvious problems with a certain directory in
the repository. Ignoring/Skipping that directory and the check
Hi,
we recently started getting this error when trying to update or
check-out a repository.
Weird thing is that the issue only occurs when we try to
check-out/update the thing externally (meaning via VPN).
Error:
svn: E720002: Can't move 'G:\Egosoft\X4\Source\.svn\tmp\svn-E78ED003' to
'G:\Eg
> > From: Edward Ned Harvey (svn4) [mailto:s...@nedharvey.com]
> >
> > So I have to just duplicate the svn:ignore and svn:global-ignores
> > properties everywhere that anything needs to be ignored.
>
> Sorry, clarification:
>
> In tortoise, I check the properties of some directory, and it shows
Hi, Nico,
Von: Nico Kadel-Garcia [mailto:nka...@gmail.com]
>
> You're still vulnerable to the "Linux clients store passwords in clear-text
> in $HOME/.svn/ by default" security issue, and if you have your Subversion
> password authentication tied to your AD accounts, it enhances the risk. It
> on
You're still vulnerable to the "Linux clients store passwords in
clear-text in $HOME/.svn/ by default" security issue, and if you have
your Subversion password authentication tied to your AD accounts, it
enhances the risk. It only takes one internal environment with poor
home directory security, or
Hi,
Von: Markus Schaber [mailto:m.scha...@codesys.com]
> I know that this problem is not strictly SVN specific, but maybe one of the
> users here has experience with this and knows a solution:
>
> I'm currently trying to set up an SVN server on linux which authenticates
> against an Windows domai
Hi,
I know that this problem is not strictly SVN specific, but maybe one of the
users here has experience with this and knows a solution:
I'm currently trying to set up an SVN server on linux which authenticates
against an Windows domain using NTLM - we want a single sign-on solution.
The vers
11 matches
Mail list logo
