I have two repositories in xp-dev with different user name and password, and i have configured TortoiseSVN svn url with the one repository, and i have folder in my file system, i am doing commit and update.
Now, i want a another folder to use other repository location, So how to have two folders synchronized with the two repositories in TortoiseSVN.
Just checkout second URL with corresponding username and password and verify results. If first user have not rights in second repo, you can even don't supply this information on start - you'll get request (after failed login)
I can't see any traces of problem exploration in your question. What you done? What was bad?
PS: Under ...\Application Data\Subversion\auth any amount of separate credentials can be stored (and stored really)
PPS: you can read about servers file and it's features and use, if you want
Related
For one of our repositories we set "Custom CI configuration path" inside GitLab to a remote gitlab-ci.yml. We want to do this to prevent Developers to change the gitlab-ci.yml file (as protected files are available in EE Premium and up). But except this purpose, the Custom CI configuration path feature should work anyway for Merge Requests.
Being in repo
group1/repo1
we set
.gitlab-ci.yml#group1/repo1-ci
repo1-ci repository exists and ci works correctly when we push to configured branches etc.
For Merge Request functionality GitLab tells us:
Detached merge request pipeline #123 failed for ...
Project group1/repo1-ci not found or access denied!
We added the developers to repo1-ci repo as developers, to be able to read the files. It does not help. Anyway the expectation is, that it is not run with user permissions, so it should simply find the gitlab-ci.yml file.
Any ideas on this?
So our expectations were right an it seems that we have to add one important thing into our considerations:
If a user interacts in the GitLab UI with the Merge Request features and you are using "Custom CI configuration path" for your gitlab-ci.yml file, please ensure
this user needs at least read permissions to that remote file, even if you moved it to another repo on purpose (e.g. use enhanced file protection in PREMIUM/ULTIMATE or push/merge protect the branches for the Developer role)
the user got this permission change applied in a running session
The last part failed for our users, as it worked one day later. Seems that they just continued working from their open merge request page and GitLab checks the accessibility out of this session (using a cookie, token or something which was not updated with the the access to the remote repo/file)
It works!
I'm hosting a bare repository on Windows Server 2008 with Windows Git and OpenSSH.
For legal reasons, I want some files to be inaccessible for a specific user but remain accessible to all other users. In other words, I want certain "restricted" files to be ignored (non-pullable) for a specific user.
Assume we have two users (Administrator and Guest) and a Git repository with 2 files : (a.txt and b.txt).
Assume "b.txt" is a restricted file that Guest should not have access to.
git clone guest#ipaddress:C:/path/to/repository.git or
git pull guest#ipaddress:C:/path/to/repository.git
should clone or pull "a.txt"
git clone administrator#ipaddress:C:/path/to/repository.git or
git pull administrator#ipaddress:C:/path/to/repository.git
should clone or pull both files.
Is there a way to achieve this result with .gitignore or .git/info/exclude?
Is there a way to achieve this result with .gitignore or .git/info/exclude?
No.
Git is all about commits, and pull (really, git fetch) and push operations transfer commits. Commits contain files—a commit consists partly of data (a snapshot) and partly of metadata (information about the snapshot)—and you either have a commit, in which case you have all the files, or you don't have a commit, in which case you don't have all the files.
Files that need restrictions for whatever reasons—legal, corporate, or otherwise—must either not be in Git at all, or stored in some sort of pre-secured fashion (e.g., encrypted). In general the "not in Git at all" approach tends to work best. Consider storing, in Git, the URL of a restricted Web site that stores the actual file.
It's not possible to restrict user access to only parts of a repository. gitignore files are designed to prevent people from accidentally checking in code they didn't intend, not to restrict access to code already in the repository.
Even solutions that limit access to refs can be bypassed by a clever attacker in a way that lets them exfiltrate data from the repository. You should assume anyone with read access to a repository can read all of the objects in that repository; if you need to restrict some users' access to certain data, it needs to either be encrypted or live in a different repository.
I'm running the maven release plugin (org.apache.maven.plugins:maven-release-plugin:2.3.2) and noticed that the password to the scm is saved in clear text in the release.properties file when passed in via the command line. I want to know if there is a way to turn this off.
I'm using Hudson to automate the release process, and the svn username and password are passed in to the command line via Hudson. The reason for this is that the person doing the release preparation can change and I have multiple hudson jobs sharing a settings.xml to release different projects.
I'm passing in parameters such as:
-Dtag=${svn.label} -DreleaseVersion=${maven.releaseVersion} -DdevelopmentVersion=${maven.developmentVersion} -Dusername=${svn.username} -Dpassword=${svn.password} -DscmCommentPrefix='[maven-release-plugin] ${env.BUILD_URL} '
The release.properties file gets created during the release:prepare, but I don't think it should be necessary as I'm passing in all the information along the command line. When this release.properties file is created it includes the password in plain text. This is problematic because it's possible to use hudson to browse the workspace, so anyone with access to hudson can see the password by opening the file via the browser.
Is there a way to not create the release.properties file, or to not save the password in the file? I realize that an encrypted password could be saved in a settings.xml file but this file is shared among multiple jobs and is not editable by the people running the jobs.
We avoided such problems letting the svn-client caching the password for us.
For this purpose we have a special account with adequate rights in subversion.
On our build server the password is stored plain text by the svn-client in the account for the user who runs hudson. For us it's no problem because only to hudson administrators have access to this account.
But you can also configure the svn-client to store the password encrypted. The configuration depends on your operating system.
svn-client configuration is stored in .subversion (linux) or "ApplicationData/Subversion" (windows).
See
here, here or here.
Just a couple of days ago somebody asked for this improvement: https://jira.codehaus.org/browse/MRELEASE-846
I have installed Nexus 2.0.6 and the integration with my LDAP server is working (authentication only). Is there a way to configure Nexus so that only a set of developers are able to deploy a given artifact, or group?
I basically do not want a developer in Team A deploying an artifact that Team B is reponsible for.
You may partition a repository using repository targets, privileges, and roles as described in this Sonatype blog post. I tested this a few months back and it seemed to work well.
Under Nexus 2.0.1, this is the solution that I've worked through and verified.
Caveats:
This allows one to restrict the "Artifact Upload" option to a directory hierarchy.
This is not quite the same as "deploy" or in conjunction with "release prepare".
Steps:
Remove the single privilege of "Artifact Upload" from all that presently have it, that you do not want to have it.
Create the "Repository-Target" that includes the directory mask of where you want to give access. Ex. .*/com/mycompany/target-dir/.* Double check the mask, it starts with period-asterisk AND ends with period-asterisk.
Create the "Repository-Privilege" that maps to the Repository-Target you just created. Typically I include the repo-name in this repository-privilege-name, like "releases.com.mycompany.target-dir". This creates the CRUD entries (4) for said directory.
Next, create the "Role" based on the Repository Privileges you just created (4), plus "Artifact Upload". Total of 5 entries for the role. Use the "Apply Filter" here to help you find these items. I name this role something like "Upload.Role.Releases.Target-Dir". Again, when finished there should be 5 entries for this role:
Artifact Upload
com.mycompany.target-dir(create)
com.mycompany.target-dir(delete)
com.mycompany.target-dir(read)
com.mycompany.target-dir(update)
This is what constrains the upload role to this repo.directory.
Create the User if it does not already exist, assign password.
Give the user the following Roles:
Nexus Deployment
Repo: All Maven Repositories(Read)
UI: Base UI Privileges
Upload.Role.Relases.Target-Dir
Hit save and you've got it. Later on, you can use this same approach to create a new Role for other repos (say Snapshot or 3rd Party), and keep the same directory mask.
I have a strange SVN server configuration issue I cannot figure out.
A previous employee setup Collabnet svn server (version 1.6.9) on a windows server at work which we use for development. It's a great system, love using it.
We use a local LAN path for the repository with all our various folders, like this...
"svn://server1"
It has one repository called "repo".
I have recently installed a second SVN on another server (same version, same OS)
It has one repository called "main". In order to access it I have to use the svn path of ...
"svn://server2/main"
So the question is.... does anyone know how we ended up with one server requiring to use a "repo name" after the server name (and does not work without it) and one server not requiring a "repo name" (and does not work with it)?
The main reason for asking is I also need to setup additional repositories on the original server and do not want to affect the current configuration. I assume this is some level or option or configuration or a "default repo" setting or something, but I just can't seem to find where and how it was set.
Check the entry in your conf file. If you have your svn information within a location tag, the location is the only way to access the repository.