- Repository— The data store containing all files and folders in the TFSC database.
- Mapping— An association of a repository path with a local working folder on the client computer.
- Working folder— A directory on the client computer containing a local copy of some subset of the files and folders in a repository.
- Workspace— A definition of an individual user’s copy of the files from the repository. The workspace contains a reference to the repository and a series of mappings that associate a repository path with a working folder on the user’s computer.
- Change set— A set of modifications to one or more files/folders that is atomically applied to the repository at check-in.
- Shelve— The operation of archiving all modifications in the current change set and replacing those files with original copies. The shelved files can be retrieved at a later time for development to be continued. This is my favorite feature.
Tag: Repository
How to configure Sonatype Nexus repository with Maven?
How to configure Sonatype Nexus repository with Maven?
Automatic dependencies is one of the powerful feature of Apache maven and its one of the reason Maven is very popular in developer community. Maven resolve the dependent library from local repository which is again connected with central repository or remote repository. thus we can say that Maven has 3 kinds of repository concept.
1. Local repostory e.g $USER_HOME/.m2
2. Central repostory e.g http://repo.maven.apache.org/maven2/
3. Private repostory e.g Sonatype Nexus, Artifactory, Archiva etc.
The diagram shown below represent how maven resolve the dependendency.
High Level Interaction between Local Repository, Central Repository and Remote Repository.
Dependency Management using Local Repository, Central Repository and Remote Repository.
This is How maven interact with Repository!
This is a diagram which shows the define flow in which maven try to resolve the dependency.
Now, We have understood that Central rrepository is in built but next questions is, How to inform the maven about the location of remote repository? In order to configure maven with remote repostory, in our case SonaType Nexus, we need to configuring host machine setting.xml and projects pom.xml to use your Nexus repos.
Put this in your ~/.m2/settings.xml file. This will configure the credentials to publish to your hosted repos, and will tell your mvn to use your repo as a mirror of central:
And now configure your projects.
If you want only to download dependencies from Nexus, put this in the pom.xml:
and
Add the following at the end of setting.xml
<activeProfiles>
<!–make the profile active all the time –>
<activeProfile>nexus</activeProfile>
</activeProfiles>
Reference
https://maven.apache.org/guides/mini/guide-mirror-settings.html
Work on remote Subversion repositories locally with Git
Work on remote Subversion repositories locally with Git
Version control is great stuff, and being able to combine different version control mechanisms is even better. Subversion is a very popular version control system and a lot of repositories (public or otherwise) use Subversion to manage files. Git is another popular one, but what happens if you are working on a project where Subversion is used but Git is your preferred version control system?
With the git-svn plugin, you can have the best of both worlds. You can convert a Subversion repository to Git, use Git tools, then push the changes back to Subversion.
To begin, you will need the git-svn plugin installed. Most likely, if your distribution of choice provides Git, it will also provide git-svn. On Fedora, install it using:
# yum install git-svn
Then use git-svn to check out your Subversion repository into Git format:
% mkdir -p ~/git/code
$ cd ~/git/code
% git svn init http://svn.host.com/svn/code
Initialized empty Git repository in /home/user/git/code/.git/
% git svn fetch
This may take a while on large repositories
r267 = 079b7c1cff49187d1aabc4b16f316102088fdc0d (refs/remotes/git-svn)
W: +empty_dir: trunk
r268 = 3f1944530a092c811c55720bd9322b8c150a535b (refs/remotes/git-svn)
…
r351 = e2af3c12e5ed174d23ffc5917f03a6136f8ebb6b (refs/remotes/git-svn)
Checked out HEAD:
http://svn.host.com/svn/code r351
At this point, the Subversion repository located at http://svn.host.com/svn/code has now been checked out in Git format. On individual files and directories, you can use the git log command as you would the svn log command in order to get history information on the item in question. With git, you will also see the Subversion commit that corresponds to the log entry, for instance:
commit 23f705cd87e1e9c6dd841ca88a14d808e0c4292a
Author: user@HOST.COM
Date: Sat Mar 20 18:25:38 2010 +0000
correct logic on the buildrequires extractor, add stats on BuildRequires to showdbstats output
git-svn-id: http://svn.host.com/svn/code@350 7a5473d1-2304-0410-9229-96f37a904fa4
With the above, you can see that user@HOST.COM did the commit, see the log message, and the Subversion revision (r350).
To work with these files, make changes as normal. git diff works like svn diff does, to see the changes made. To commit changes, use git commit like you would use svn:
% git commit -m “some minor change” file
[master 2454be1] some minor change
1 files changed, 2 insertions(+), 0 deletions(-)
To update your local copy from Subversion, instead of using svn update use git svn rebase. This will merge in any changes found in the Subversion repository.
When committing files using git commit, you are committing your changes to the Git repository. None of these changes are pushed to the Subversion repository until you specifically tell Git to do so. This is done with the git svn dcommit command, which then takes each commit made to Git and pushes them to Subversion as individual commits, which will retain all of your history and log comments:
% git svn dcommit
Committing to http://svn.host.com/svn/code …
M trunk/rqp
Committed r352
M trunk/rqp
r352 = 0557314a580c4390ff646380baa3aa33d1f6a5cd (refs/remotes/git-svn)
No changes between current HEAD and refs/remotes/git-svn
Resetting to the latest refs/remotes/git-svn
Unstaged changes after reset:
M trunk/rqp
M trunk/rqp
Committed r353
M trunk/rqp
r353 = 249e97283ad28126bf84ccaffb32873e12d15b7b (refs/remotes/git-svn)
No changes between current HEAD and refs/remotes/git-svn
Resetting to the latest refs/remotes/git-svn
Now, if you were to look at the changed file(s) in Subversion (via another Subversion working copy or something like ViewVC), you will see the individual commits. Above, there were two changes made to the trunk/rqp file, each committed locally to Git. The “dcommit” command pushed those changes as individual commits to the Subversion repository. In this way you can do all local development with Git and when you have something you want to commit to the Subversion repository, you can push all of the relevant changes at once, retaining each separate commit.
Using the git-svn plugin makes it extremely easy to use Git locally with a remote Subversion repository. If you are in a project or organization that, for whatever reason, does not want to convert to Git, you can continue to work with that Subversion repository, without the restriction of using Subversion yourself.