Here's a basic sh script syntax.
# Check forbidden mergeinfo paths
TXN_PATHS=$($SVNLOOK changed -t "$TXN" "$REPOS")
# Grep for paths *not* in merge-allowed levels: /trunk,
/branches/release/*,...
TXN_PATHS=$(echo "$TXN_PATHS" | grep -Ev "^trunk/?$" | grep -Ev
"^branches/release/\w+/?$" |
We are running VisualSVN 1.9.3 server on a Windows box and a user's workspace
is on a Centos6.5 Linux box.He had just done a "svn update" and the build
failed. No conflicts as far as I can tell. The "svn status" showed the build
artifacts and his modified files. As a suggestion, he would "svn
It was 1.8.14 client.
It just said "Reverted " and the subsequent "svn status" made no
mention of the . Brent
From: Johan Corveleyn
To: webster.br...@rogers.com
Cc: "users@subversion.apache.org"
Sent: Thursday, March 3, 2016 3:29 AM
Subject: Re: Weird Behaviour: Files reverted th
These files were never changed in the first place, that's the weird part.We
aren't using any local locks in the repo. Brent
From: Johan Corveleyn
To: webster.br...@rogers.com
Cc: "users@subversion.apache.org"
Sent: Wednesday, March 9, 2016 4:10 AM
Subject: Re: Weird Behaviour: Fi
Server 1.9.3 (Windows) and client 1.8.15(Linux-Centos6.5)
We are in the mist of refactoring our directory structure from the monolithic
(Clearcase imported) directory structure to moving subdirectories to new
repositories and using svn:externals with pegged versions back into the primary
product
Env: Server 1.9.3 (Windows) and client 1.8.15(Linux-Centos6.5) being run by all
users.
We are in the mist of refactoring the directory structure. i.e. What's the
process when converting a directory to use svn:externals?:
http://mail-archives.apache.org/mod_mbox/subversion-users/201603.mbox/%3C18
Johan, thanks for the insights/efforts. Sorry about html --- damm Yahoo mail.
It is possible that these files were chmod'd but I can't confirm now. It is
good to know that changing file permissions won't be detected by a "svn status"
but will get reverted. I've got 100+ exClearcase designers th
As the subject line states I want access control to prevent the creation of
files and directories at a certain directory level and above. Below that
point, the general population can make whatever changes they deem fit. Another
requirement I have is to always merge from the top level but that
You should wrapper the diff command
svn diff --diff-cmd 'diff -x -w' Brent
From: Branko Čibej
To: users@subversion.apache.org
Sent: Wednesday, May 4, 2016 11:01 PM
Subject: Re: Blank lines
On 04.05.2016 22:58, Daniel Shahaf wrote:
> Eric Johnson wrote on Wed, May 04, 2016 at 09
My mixed revision working copy remains mixed revision after multiple attempts
with 'svn update'.Here's the final status output:
[linux] >> svn st -u
X vobs/common/cpCommon
X vobs/common/dclCommon
X vobs/ots/broadcom/BCM_SDK_6.4.11
X
Yes, these externals are deliberately pegged and I have other working
copies(WC) based on the exact same checkout and they show up as a single and
not a mixed revision WC.
Of the 108 WCs I've looked at, 36 are in a mixed-revision configuration and
that's OK but in several cases, these WCs cannot
As an amendment, I created one more WC with my 1.8.16 svn client at the
original XXX revision. (i.e. prior to the directory deletion and subsequent
addition of the svn:externals). I then updated the client to 1.9.4 and ran the
'svn update' where it successfully deleted the directory and then ad
12 matches
Mail list logo
