With Subversion (SVN) we can view versioned files over HTTP i.e. we can view a Java file in a browser by supplying a URL such as:
http://teamserver/svn/repos/project/trunk/MyClass.java
Is it possible to do something similar with AccuRev? I only require read access to the file.
Absolutely. You simply need to install the AccuRev WebUI, which you can download and install as a licensed AccuRev customer.
http://www.accurev.com/download.htm
Related
MercurialEclipse' homepage has links to an update site and, indirectly, to downloadable archives. I can't use the update site since my machine is not connected to the Internet, so I'm downloading the archive on a connected machine and copying it to the target machine.
But now - what do I do?
Putting the JAR file (com.vectrace.MercurialEclipse_2.1.0.201304290948.jar ) in the 'dropins/' folder has no effect.
Putting the JAR file in the 'plugins/' folder also has no effect
Eclipse will not treat the archive as an update site (using Install New Software | Add)
So how do I install this thing?
These steps are untested but they should replicate the update site on your local file system:
Clone this repository: https://code.google.com/a/eclipselabs.org/p/mercurialeclipse.wiki/
Download the stable plugin jar file from the downloads section and place it in update_site/stable/plugins
Edit update_site/stable/site.xml and remove all the <archive ..> elements.
We've got a "bare" git repository on a server, for a Web portal project. Several programmers, designers, etc... perform dozens of push and pull from/to it.
Now we want to test the project on the server itself, and always test the last commit through an Apache web server which is installed on the same machine the "bare" git repository is stored in.
How can we 'unbare' the repository, and let the working directory contain always and only the last commit deriving from the last push?
Or anything else aiming to achieve the same result?
You can use a post-receive hook to do a git pull inside your webserver document root/repository.
in your bare repository
do
mv hooks/post-receive.sample hooks/post-receive
chmod +x .git/hooks/post-receive
the post receive should be something like
#!/bin/sh
WEB_ROOT='/var/www/project'
cd $WEB_ROOT
git pull
A more elegant solution that doesn't involve that the web server area being a git repository, you can also review the git documentation about hooks
Note: if you use the simple solution, please make sure that your webserver doesn't serve the .git directory, this would give some hackers/crackers the access to the website source code!
I'm using Trac 0.12.2 that came as a part of Bitnami Trac Stac.
I am very new to Trac & just started with Trac, working with a local repository on a desktop a few weeks ago & created some issues. Now I wanted to transfer the all those issues onto my new Trac installation on another desktop. So I simply tried replacing the empty(I believed) database folder of new installation with my old Trac DB folder.
Specifically this folder:
C:\BitNamiTracStack\repository\db\
When I tried doing so, the admin tab on the trac interface disappeared.
Also I got a message:
Warning: Can't synchronize with repository "(default)" (The repository directory has changed, you should resynchronize the repository with: trac-admin $ENV repository resync '(default)'). Look in the Trac log for more information.
How do I successfully transfer my issues from one desktop to another ?
Check your installation and find the correct directory called 'Trac environment' as per Remy's advice.
While his answer is the safe road and general advice without doubt, you may still succeed with a less complete transfer, depending on what you already put into the Trac environment in question. Assuming you do use BitNami's default Trac db backend (SQLite) you'll need at least
the latest db named trac.db from the db folder
the configuration file conf/trac.ini
If you've worked with attachments to tickets or wiki pages, the whole directory structure below attachements is needed as well.
Other things might not have been touched by a self-declared "very new" Trac user within the first weeks. Of course a diff -Nur <path_to_old_dir> <path_to_new_dir> | <your_favorite_editor> will remind you of anything you may have already forgotten.
You shouldn't copy the database alone, but the complete Trac environment. That's the directory containing the attachments, conf, db, htdocs, log, plugins and templates directories. In your case, this seems to be the directory:
C:\BitNameTracStack\repository
(I'm not familiar with the BitNami stack, but the name "repository" sounds suspect. I hope they don't put the Trac environment below the Subversion repository.)
See the official Trac documentation on backing up a Trac environment and restoring it. You should be able to use this to migrate your config to another server.
XEmacs always creates a file named foo.txt~ when you edit foo.txt. This can be really useful but not really when you are using source control on your files.
I know you can use (setq make-backup-files nil) to turn it off altogether but was wondering if there was a way to turn it off only in particular directories.
The version control package will detect if you're in a CVS, RCS, or SCCS repository and disable backups. If you're using another VC backend like hg, git, or svn, you may need to install additional packages to enable emacs to detect their repositories.
http://maven.apache.org/settings.html As per documentation the user specific settings can be either copied to the .m2 folder or under the maven installation. If a developer changes a machine or gets a new user id, such properties have to be copied manually to these newer machines.
Would it be possible to store user specific setting information in the repository itself (say SVN) and somehow have the mvn scripts load it on startup.
If the content of the settings.xml is not that user specific (e.g. for mirrors), you could store the whole Maven install in SVN with a customized conf/settings.xml and have the developers grab it from SVN to "install" it on a new machine as described in this previous answer.
If the content of the settings.xml is really user specific (e.g. it contains secret things like passwords), then it must be located in ~/.m2 and you will have to somehow make it available at the new location. If a developer logs on another machine, you could use "Roaming user profile". If a developer gets another id, then you'll really have to duplicate it. The technical solution may depend on the level of confidentiality required.
And if you have several developers sharing a userid but still need different settings.xml, then you'll have to pass it to Maven using the -s option. One could imagine storing these custom settings.xml in the project in that case (assuming it doesn't contain sensitive information). For example:
mvn -s settings-user1.xml <goal>
Nope, the whole point of having user settings is to store them outside the maven projects. There's nothing stopping you from creating your own svn repository and storing your configuration files there, though. You could write some shell scripts to bootstrap a new workstation from that repository, but it really depends how often you do this to make it worthwhile.
I would suggest that you setup your own repository such as Archiva, Nexus or Artifactory. Which will get your dependencies/plugins , then you can use mirror to specify explicitly just one repository to be used(the one you setup on your network). So whenever developer changes machine or dependencies are needed for multiple developers the internal mirror can be used as repo, your dependencies/plugins will download in no time to your local repository/ies