Lets Disucuss best way to implement Hook with SVN?
This is very useful content to know aboutr hook in SVN
svnbook.red-bean.com/en/1.1/ch05s02.html
pre-commit hook, what is the best way of implementing using ActiveDirectory accounts, and the right way to test it before implementing it in real?
What are the advantage of GIT over Subversion and perforce?
Code development has its negative and positive sides, but anything that brings more relief and gains time in a project is the developer’s best friend. CVS was for a long time the best solution for version control, adopted by all programmers in major projects. While CVS has slowly evolved into other more successful concurrent version systems like Subversion, the latest trend that manifests across the development world is the usage of DCVSs (distributed version control systems) as the main project tracking managers.
Since its launch in the mid ‘80’s and till 2000, CVS was the only real alternative as a revision control system for programmers. Not a very good one, but better than anything else. Built in 2000 by CollabNet Inc., Subversion was marketed from the start as “a better CVS” and “CVS done right.” It was truly better than CVS; unfortunately, it didn’t bring in that many new features, and under the hood, nothing has changed its core.
Because of that, there was a surge in revision control software development at the start of the 2000’s, which led to the birth and development of many DCVS projects. GNU arch and Monotone where about the first to be launched, followed by Darcs and BitKeeper.
A serious step in DVCS’ development took place after the quarrel between Linux developers and BitKeeper’s management, after BitKeeper accused one of the Linux developers of reverse engineering one of their commercially licensed features. Soon after, Linux programmers led by Linus Torvalds himself released Git as an improved open source solution to BitKeeper’s soft. Besides Git, Mercurial and Bazaar were also very successful alternatives to SVN, sharing many of Git’s features, but lagging in performance.
While SVN (Subversion) was extremely popular at the beginning, it established itself as the premiere solution in code development. Soon after, as DVCSs were developed and released, users migrated to them, abandoning SVN, opting for the more loose and faster solutions.
Nevertheless, old CVS users still tend to linger around SVN due to its familiar interface and old coding habits established over the years. Many of them question to this day Git’s efficiency in quickly putting versions together, while Git supporters, on the other hand, criticize SVN’s stiffness regarding offline work.
In many cases, the debate between Git and SVN supporters usually starts with the following features, or lack.
Git features
Offline work: Git permits any developer to branch a project and store it in a local folder as a standalone repository. After doing all the work offline, the central server or storage unit, they can than simply merge it with the central repository committing all the changes already made. This permits developers that don’t have Internet access all the time to work on a project with ease.
Central project information: Unlike SVN, which uses a .svn folder in each directory, Git uses a central .git folder in the checkout root for all project data and logs. This way, it’s easier to track changes to specific folders, on specific dates or by certain development teams. Thus, project code management is much more simplified. This also allows easy renaming of files or folders, Git automatically transmitting these changes in its history.
Easy branching: Branches and tags are much easier to create and switch in Git.
Merge history: While SVN has a branch merge history, it records all the events as coming from one user (the merger). In case a user has previously worked on a file and has not merged it, if that file is merged by another user, all the changes will be attributed to the user that merged the branch. Git, unlike SVN, can remember file changes beyond a merging point and track every user’s actions beyond project commits. Git also automatically starts the next merge at the last point it recorded.
Disk space: When the Mozilla project was ported from SVN to Mercurial (very similar to Git in performance), disk space usage went down from 12GB to 420MB, 30 times smaller than the original size. Git is supposed to use the same storage algorithms, so file size should be around the same value.
Speed: This is a no-brainer. Because all operations except for push or fetch are performed locally, Git’s speed is overwhelmingly faster than SVN could ever supply.
Better access and administration: SVN relies on an authentication module and access lists to permit users to push and merge branches. Git reduces the time spent for providing commit access to users and just lets the administration team decide what to merge and from whom.
Synchronization: It can occur over various types of media like an SSH channel, over FTP, HTTP, WebDAV, or by emails holding attached patches.
SVN features
GUI: From the beginning, SVN users have been using a GUI when managing their repository. This feature is not found at all in Git, a port for TortoiseSVN still being in the works. Besides the lack of a GUI, Git, coming from a UNIX environment, has a very complicated CLI interface with many options and arguments for its base commands.
Single major repository: Other may say this is not a good thing, but it’s a strictly SVN-specific feature. While Git allows each individual user to copy the entire repository on their computer and work on the project’s code, Subversion has always relied on permissions being given to users to only work on one single repository stored online. This feature allows the developer to always be able to download the latest version of their project without having to wait for all that work on the project to log online, upload and merge their latest branch. This is very useful in fast development environments or application troubleshooting.
Partial checkouts: Git doesn’t offer the possibility to download only a single folder from the repository. This may be a disadvantage to developers not having great bandwidth or speed.
Version numbers: Another keeper from the UNIX fathers of Git is the complicated version control numbers. While SVN uses a simple incremented decimal system, Git employs an SHA1 algorithm to output a 40-character hexadecimal string as the version number. This could get very tiring when having hundreds or more versions.
The abovementioned features are only a scratch on the surface when discussing about the version control system war between CVS/SVN supporters and DVCS users. More on the topic can be read here, which puts all the major platforms’ features next to one another so they can be compared.
Let’s now take a look at the parties involved and analyze their impact on the current programming and development world.
Subversion, as of 2009, was recently included in the Apache Incubator project, mainly because of its long usage history in most of the Apache Foundation’s projects. More details are available in one of my past articles on this topic. Other famous open source or commercial projects that have a weakness for SVN include market players like Ruby, Mono, Free Pascal, ExtJS, Tigris, PHP, MediaWiki, GCC, Django and FreeBSD. All having their source code administrated from an SVN repository.
On the other hand, the community’s favorite project, Git, is currently expanding its horizon every day, recently taking GNOME and The Perl Foundation away from SVN, placing them alongside other notable Git-powered projects like Android, Linux, openSUSE, Yahoo User Interface, x264, Digg, jQuery, X.org, Samba, Ruby on Rails, CakePHP, Fedora, Merb, Freenet, GIMP, Parrot, Qt, rsync, Wine and VLC.
Other Git-like products like Mercurial (originally designed to replace BitKeeper for Linux development) have also been adopted by major corporations and programs like Mozilla, OpenJDK, OpenSolaris, Netbeans, OpenOffice, Vim, SAGE, Growl, Wget, Symbian OS and Adblock Plus. In 2010, The Python Foundation is going to join this list, migrating from SVN.
Another Git-like DVCS platform, generally regarded by the community as being slower than Git, but much easier to learn is Bazaar. This is a product developed especially for Ubuntu, but which saw adoption in many other projects around the web, some of them like Squid, APT, MySQL, GNU Emacs, Gnash and Inkscape.
The trend is easy to see. DVCSs are adopted in more and more projects, while SVN is headed for the history books alongside its precursor, CVS. The final battle in this version control systems war is being waged on the grounds of project storing platforms the likes of SourceForge, Google Code or CodePlex. The winner of this confrontation will surely decide whether SVN will be used in the coming future or whether it will fade away from our minds like the early PC consoles.
Currently, SourceForge and GNU Savannah have the biggest and widest hosting platforms, providing version control platforms like CVS, SVN, Git, Bazaar and Mercurial to all of their users free of charge. For SourceForge, by default, a project will be hosted on Subversion. The same happens in Google Code, where SVN is the default, but the Mountain View-based crew also provides Mercurial as a DVCS alternative. Renowned hosting platform, CodePlex, provides SVN, Mercurial and Microsoft TFS hosting, while the smaller service on Project Kenai offers SVN, Git and Mercurial.
Also lately, due to high technical costs, services are starting to opt only for one version control system, putting some heat in the discussions between the CVS communities. The list is as follows: Mercurial has exclusivity on Bitbucket, Bazaar on Launchpad; Git on Github, Codaset and Gitorious, and SVN on BountySource, Freepository, GridyZone and Origo. A slim crop for SVN, but being the default service on Google Code and SourceForge might give it a fighting chance against the up-and-coming Github.
Some of you might not agree with the previous claim that this is a “battle” and should not be at all compared with the browser wars, but the community deeply rooted in the tech world already knows this is more of a fact than a myth. As proof of concept, we bring you this video from a conference at Google back in 2007, where Linus Torvalds, the inventor of Linux and Git, made some outrageous statements regarding SVN, and especially its users.
If you don’t have the time to view this one-hour long video, we’ve listened to the conference and taken some interesting quotes from Mr. Torvalds: “Subversion has been the most pointless project ever started,” continuing with “Subversion used to say CVS done right: with that slogan there is nowhere you can go. There is no way to do CVS right” and ending with “If you like using CVS, you should be in some kind of mental institution or somewhere else.”
Not very heart-warming comments from a public person like Linus Torvalds. Especially being made in the headquarters of one of the companies that have ignored Git and failed to include it in the Google Code project. Nevertheless, Mr. Torvalds might also be under the influence of an inner demon, specific to most UNIX users to prove that any project developed and coming from a Linux environment is better than anything else.
True or not, Git has seen a rise in usage, as proved by the 2008 and 2009 Kernel.org surveys, which had it ranked above any other versioning control platform like SVN, Bazaar and Mercurial, and with a crushing 94.6% rate of overall satisfaction toward the Git user experience. As a conclusion, it is generally acknowledged that future versions of Git will be adopted in more and more environments, and Git will have to fight only against other DVCSs for supremacy in the programming world.
One more good link for Advantahe of git over SVN(Subversion) …
http://markmcb.com/2008/10/18/3-reasons-to-switch-to-git-from-subversion/
Next Generation Software Configuration Management with Subversion
Next Generation Software Configuration Management with Subversion
Version control systems play a vital role in the success of a software development team. This blog aims to provide a simple branching and merging strategy to manage the code in a fast paced team development environment.
When do you need branching?
You may need to adopt branching in many different scenarios. Let us assume that on a day to day basis you use agile methodologies such as extreme programming or scrum and you have finally released a reasonably complex project with Version 1.0.0.0. Couple of days after the release, you get a request for a new feature that must go as Version 1.1.0.0. You envision it will take couple of weeks to get that feature coded, tested and released. Meanwhile, simple modifications and patches are requested on a day to day basis in the Version 1.0.0.0.
Essentially, with the changing business needs you are required to do a deployment every other day or so i.e. your deployment cycle is 2 days or less.
With a team of 10 developers it will be a nightmare in the absence of a proper branching strategy.
Trunk, branch, and tag are the 3 main divisions in subversion repository.
Trunk:
The code in trunk is always maintained as close to release state as possible. Any developer making changes to the trunk must be absolutely certain that his or her part can be coded, tested and is ready to deploy within 2 days (can vary depending on your length of deployment cycle). If it takes more than 2 days, they are not allowed to directly change the code in the trunk. They have to create a branch.
Branch:
Developer Branch:
Each developer must create his or her own branch if their code will take more time to program than your normal deployment cycle. It is the responsibility of the developer to regularly (timeframe depends on your development environment) merge changes from trunk to his branch.
Feature branch:
Create a feature branch if 2 or more developers are going to work on a new feature that will take considerable time to complete. It is the responsibility of the team lead to merge changes from trunk to this feature branch on a regular basis.
It is always beneficial to merge changes from trunk frequently. Because, after a couple of days conflict between trunk version and branch version can get out of hand and merging will practically be impossible.
When the developer branch or feature branch is ready for release, merge changes back from the branch to trunk.
Tags:
Tag is similar to branch. When you create a branch simply rename the folder from branch/branches to tag. I always use Tags to tag a release whenever a new release version is deployed. This will come in handy if a very minor patch has to be made on the release version when your trunk is temporarily dirty. Ideally, you do not merge from trunk to the tag.
Finally, remember that there is no ideal branching and merging strategy. It pretty much depends on your unique development environment. If you have any other strategy, I would like to hear about that.
It is an exciting time for Subversion as its adoption continues at a dizzying pace in enterprises. I’m out there helping that adoption so I’m a bit late in posting the questions and answers I promised around the three basic branching strategies that I covered in the last two webinars in which I presented (Branching and Merging Strategies for Subversion 1.5 and Advanced Merge Tracking and Branching with Subversion 1.5). Hopefully these will be useful to many of you.
First, a quick reminder on what the three branching strategies were:
1. The unstable trunk which mimics the way that Subversion itself is developed. In this model, development is done on the trunk and a release branch is created around the time of feature completion with the formal promotion process carried out on that branch.
2. The stable trunk where development is done on system version branches and the promotion process is also conducted on that branch. The trunk is the branch point where the production releases are merged in and parallel development efforts are branched out.
3. The agile release strategy where development is done on individual feature branches and a release branch is created late in the process with the feature branches merged to it that will define that release. The formal promotion process is conducted on the release branch and the production version merged to the trunk as well as to all remaining active feature branches.
So on to the questions, first general branching questions:
Does the number of branches affect performance of the Subversion server?
No, branches are not just cheap in space and fast to create, they are alo just additional paths not unlike directories in the directory structure of your project. Of course, every tool has scalability issues at some point and Subversion logically has its limits, but in practical use, a scalability issue for Subversion around branches has not yet been experienced.
Can we use multiple strategies on one project?
Absolutely, there are many times when you may find a need to mix at least two branching models on the same project. For example, Internet applications may have very frequent releases focused primarily to address defects along with longer term release efforts to address broader feature development. The frequent releases may follow the unstable branch approach where they are worked primarily on the trunk and are branched, sometimes weekly or even more frequently, to do the formal QA to get to the release. The longer running enhancement releases may use the stable trunk philosophy though obviously the trunk isn’t actually stable, but the rest of the strategy is followed.
What strategy is best for a repository with multiple projects?
There is no need to have a single strategy in such a case. Instead one should use the appropriate method for each of the projects. Since each project should have its own top level directory for its branching model, there is no reason to force a particular method on all projects.
How does continuous integration affect branching strategies?
I’d hope that this isn’t the deciding factor in determining an appropriate branching strategy, but certainly the feasibility of continuous integration is impacted by the strategy chosen. With the unstable branch, continuous integration would be focused on the trunk and thus is stable as well as very useful as it identifies issues in the daily development commits. This is still relatively true when you look at the stable branch strategy where there may be multiple system version branches under development at the same time, but each is the focus of the majority of the development commits. The agile release model is the least accessible for this approach because of the number of active branches to try and monitor. That doesn’t mean continuous integration can’t be used but just that it is more difficult to implement and maintain.
Unstable Trunk questions:
Can this model handle parallel development if it only happens occasionally?
Any model can be morphed to handle exceptional situations, but this isn’t recommended. It is important to use a strategy consistently so that everyone understands where to find things during development and historically. That said, we’ve already talked about the potential of using multiple strategies on the same project so that’s certainly a possibility where the parallel development need could be addressed like with the stable trunk strategy.
Do I ever recommend merging from the trunk to the branch?
Never say never, but the situation would be pretty rare. I could potentially envision where a nearly complete bug fix or even an enhancement of importance is completed quickly enough on the trunk that there could be a compelling reason to merge it into the unreleased, but branched version.
How would you handle branches for customers that will have ongoing customizations for individual customers in this model?
Branches for this purpose can really be applied to any of the three basic branches we’ve discussed. The concept is that the base product continues to evolve and the branching strategy addresses that evolution. As production releases are made, the new revisions are merged to the customer-specific branches which contain customizations for that customer. There is also the potential of customer customizations being merged into the base product. The customer branches support the unique nature of customer specific changes while allowing for an upgrade path and the potential of contributing back to the base product.
Stable Trunk questions:
Version 1.0.1 didn’t get merged back into the trunk, shouldn’t it have been merged back?
Possibly, but I actually didn’t do so on purpose. With all the models, there is the potential that multiple releases are deployed in production and thus need to be supported. Therefore, there is the potential that bug fix releases are being made for multiple releases and merging all of them back to the trunk could mean intertwined versus serial releases. I therefore usually suggest that the actual production releases may be the only ones merged. Obviously, in my diagram that situation didn’t occur so it is a fair question.
There is a merge to the trunk outside of a release point, doesn’t that violate the stable trunk idea?
Yes, that can violate the stable trunk concept, but stability isn’t necessarily limited to just production releases. In this case, the purpose is to have a more up-to-date starting point for the system version branch. How strict you implement the idea of stability is up to you.
Should the development team develop the first version in the trunk or in a release branch?
Since my base principle is keeping it simple, I tend to say do the development on the trunk since there is no reason for creating a branch. The assumption is that parallel development won’t happen until the first release is made and other work won’t be merged until the release. This isn’t being pure to the strategy, but true to the base principle.
Agile Release questions:
In this strategy, is there any attempt to keep the task branches in sync with each other?
No, there really isn’t any way to define how you would keep isolated tasks in sync since there is no idea what will be released together until we get to the definition of the release branch. There is a need to keep the branches sync’d with production releases, but no way to do more.
Is there any reason that an Internet application should NOT be using the agile release method?
Sure, there are still many such applications that are released in a waterfall manner and are unquestionably successful. For example, release agility may not be required if releases are being made frequently enough. Keep in mind that there is more to keep in sync in this model which has to be balanced against any benefits.
Where is the release package built from?
I think the package would be built from the release branch since that’s logically where the promotion model process is conducted, but it can certainly be argued that the testing can be done on the release branch and then the approved revision merged to be tagged from the trunk. My absolute expectation is that you be consistent where you do build and tag.
How can a CM manager make sure all task branches were merged to the release branch?
Today, I would suggest the use of svnmerge.py where merge tracking is recorded in a property for all branch merges. Obviously, this will be easier with 1.5 where the log command can expose this information. Another approach would come from integrating issue management with Subversion where the merges would be reflected in the record for the release.
I’m sure I’ll return to answer some more questions around these branching models and merge tracking before long. Right now, I’m off to help another enterprise successfully implement Subversion.
Reference:
http://www.codelathe.com/blog/index.php/2009/07/02/a-svn-branching-strategy-that-works/
http://stackoverflow.com/questions/34975/branching-strategies
http://blogs.open.collab.net/svn/2007/11/branching-strat.html
http://www.javaworld.com/javaworld/jw-01-2008/jw-01-svnmerging.html
http://www.codinghorror.com/blog/2007/10/software-branching-and-parallel-universes.html
http://www.cmcrossroads.com/forums?func=view&catid=75&id=78871
rajeshkumar created the topic: Apache2 LDAP authorization for Subversion with OpenDS
Apache2 LDAP authorization for Subversion with OpenDS
There are several ways to enable user authentication for web based applications, like .htaccess files, plain tekst files, databases, LDAP, etc. They all have their pros and cons. In case a central, flexible solution is needed, either a database or LDAP solution can be used.
I chose for an LDAP solution since it can be reused by many web and application servers and the applications that run on them while many LDAP solutions provide excellent tooling and easy configuration. Since Yenlo strongly focuses on GlassFish and other Sun tools, I chose OpenDS to authenticate against.The idea is to create a bunch of users and put them into one or more groups. Each group gets access to one specific Subversion repository and every user that needs access to a certain subversion repositoy needs to be in the corresponding group.
This blog describes the basic steps I took to get Basic HTTP authentication for Subversion using Apache2 and OpenDS.
Setting up the server
The server is running on Debian Etch, for which most of the required software is available via the Debian package repository. The packages I installed are
apache2
apache2-mpm-prefork
libapache2-svn
subversion
sun-java6-bin
sun-java6-jdk
sun-java6-jre
Apart form these packages I downloaded and installed the OpenDS 2.2 zip file from the OpenDS homepage. For this purpose I created a user and a group called “opends” and the directory /usr/local/opends which I gave both ownership and group “opends”. Next I logged in as user opends and extracted the zip file into that directory. Finally, as root, I created a start and stop script and used the update-rc.d script to make sure OpenDS is automatically started and stopped when the server is started and stopped.
Setting up Subversion
Let’s suppose that our organisation has decided to create a Subversion repository for each development project that we do. This means that we would get a directory structure like this, with the leaves being the root directories of each repository:
/usr/share/subversion
/repository1
/repository2
The repositories were created as root using these commands in the /usr/share/subversion directory
# svnadmin create repository1
# svnadmin create repository2
That’s all the configuration that was done to the Subversion repositories.
Configuring OpenDS
First, a basic setup of OpenDS needed to be done using the command
$ /usr/local/opends/OpenDS-2.2.0/bin/setup
For more info about this, see Setting Up the Directory Server. Please note that if you are not running OpenDS as root user, it will listen on port 1389.
The next step was to configure OpenDS so it contains a few users and groups. The main configuration tool for OpenDS is called control-panel and, in my case, it can be started as user “opends” by issuing this command:
$ /usr/local/opends/OpenDS-2.2.0/bin/control-panel
With this tool, among other things, you can manage the entries in the directory. For my purpose I created the next layout
base dn (dc=yenlo,dc=nl)
organisation (o=yenlo)
organisational unit (ou=devel)
user (uid=wouter1, password = wouter1)
user (uid=wouter2, password = wouter2)
user (uid=wouter3, password = wouter3)
group (cn=group1, uniqueMember=wouter1,wouter2)
group (cn=group2, uniqueMember=wouter2,wouter3)
which is a very simple layout but sufficient for now. Note that I created two Subversion repositories and therefore two LDAP groups, one for each Subversion repository.
Setting up Apache2 to get access to the Subversion repositories
First I configured Apache2 so the two repositories were accessible to anyone using e.g. a web browser. After libapache2-svn is installed, the module should be enabled in the Apache2 configuration files automatically. To verify this, check the
/etc/apache2/mods-enabled/
directory and make sure these symbolic links exist
dav.load -> ../mods-available/dav.load
dav_svn.conf -> ../mods-available/dav_svn.conf
dav_svn.load -> ../mods-available/dav_svn.load
If the first link is missing, create it as root using
# a2enmod dav
If the second and third are missing, create it as root using
# a2enmod dav_svn
To make sure the modules are loaded by Apache2, restart the server as root using
# /etc/init.d/apache2 restart
Now some modifications need to be made to the dav_svn configuration file
/etc/apache2/mods-available/dav_svn.conf
The idea is that there are two Subversion repositories that need to be configured individually. So, these two entries need to be put in the above mentioned configuration file
DAV svn
SVNPath /usr/share/subversion/repository1
SVNListParentPath On
SVNAutoversioning On
SVNReposName “Repository1 Subversion Repository”
DAV svn
SVNPath /usr/share/subversion/repository2
SVNListParentPath On
SVNAutoversioning On
SVNReposName “Repository2 Subversion Repository”
Now, if you point your browser to either http://
Adding LDAP support using OpenDS
In order to use LDAP atuentication with Apache2, these two entries should be present in /etc/apache2/mods-enabled:
authnz_ldap.load -> ../mods-available/authnz_ldap.load
ldap.load -> ../mods-available/ldap.load
If they aren’t present, you can enable them as root with these commands
# a2enmod authnz_ldap
# a2enmod ldap
# /etc/init.d/apache2 restart
Now, each
AuthType Basic
AuthName “Repository1 Subversion Repository”
AuthBasicProvider ldap
AuthzLDAPAuthoritative off
AuthLDAPURL ldap://localhost:1389/dc=yenlo,dc=nl?uid
AuthLDAPBindDN “cn=Directory Manager”
AuthLDAPBindPassword mypassword
AuthLDAPGroupAttribute uniqueMember
AuthLDAPGroupAttributeIsDN on
Require ldap-group cn=repository1,ou=devel,o=yenlo,dc=yenlo,dc=nl
Issue a final
# /etc/init.d/apache2 restart
and you should be prompted for a username and password when you try to access either repository. Using the correct uid and password combination should grant you access to the repository.
Next stepts
The authentication mechanism we chose, Basic autentication, posts usernames and passwords in plain text, which potentially could be harmful in case someone sniffes the connection. I would strongly recommend to setup SSL based connections. Moreover, this blog post only shows how to secure one repository layout using LDAP. Both Subversion and Apache are sufficiently flexible that other layouts are possible. Those layouts most likely require tweaking of the Apache2 configuration options. Finally, I am not an LDAP expert so the directory structure I chose in OpenDS most likely can be much improved. However, following the steps in this article should get you on your way to using OpenDS incombination with Apache2.
Reference: Referencehttp://www.yenlo.nl/woutervanreeven/2010/03/15/apache2-ldap-authorization-for-subversion-with-opends/
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn
rajeshkumar replied the topic: Re:Apache2 LDAP authorization for Subversion with Opends
Subversion authorization through LDAP with OpenDS
If you building a centralized development environment for a team or large group of users, the question of centralizing user identities, authentication and authorization is always popping up and the answer is often to use an LDAP directory server. The developer section of the OpenDS documentation wiki has a set of tutorials for using the OpenDS LDAP directory server with various web servers and open source project like GlassFish, Apache Tomcat, SugarCRM… But not yet for Subversion. Thankfully, Wooter van Reeven, Senior Consultant at Yenlo has just published a long and detailed tutorial for setting up Subversion authentication and authorization through LDAP, with OpenDS and Apache2.
blogs.sun.com/Ludo/entry/subversion_auth…on_through_ldap_with
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn
rajeshkumar created the topic: Hook to make Subversion Read Only for specific use
Hook to make Subversion Read Only for specific users
We have an existing Subversion repository that uses LDAP to manage users/passwords. There are some new users who we would like to provide read-only access to SVN. I did some Google searches and found a way to open up read-only access to anonymous users, but this is not what we want. We do not want to open up SVN to everyone. We still want to control login through LDAP, but we would like to prevent certain named users from being able to add/edit/delete.
I am assuming this can be done with a hook (pre-commit?), but I have no experience writing hooks. Can someone show me or point me to an example of how to do this?
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn
rajeshkumar replied the topic: Re:Hook to make Subversion Read Only for specific use
I use an LDAP setup with config similar to:
in /etc/apache2/sites-enabled/mysite
DAV svn
SVNParentPath /var/svn
SVNListParentPath on
AuthBasicProvider ldap
AuthType Basic
AuthzLDAPAuthoritative Off
AuthzSVNAccessFile “/var/svn/conf/svnaccess.conf”
AuthName “My SVN”
AuthLDAPBindDN “…..”
AuthLDAPBindPassword “…..”
AuthLDAPURL “…..”
Require valid-user
/var/svn/conf/svnaccess.conf
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn
rajeshkumar replied the topic: Re:Hook to make Subversion Read Only for specific use
I use an LDAP setup with config similar to:
in /etc/apache2/sites-enabled/mysite
DAV svn
SVNParentPath /var/svn
SVNListParentPath on
AuthBasicProvider ldap
AuthType Basic
AuthzLDAPAuthoritative Off
AuthzSVNAccessFile “/var/svn/conf/svnaccess.conf”
AuthName “My SVN”
AuthLDAPBindDN “…..”
AuthLDAPBindPassword “…..”
AuthLDAPURL “…..”
Require valid-user
/var/svn/conf/svnaccess.conf
[groups]
readonly = user1, user2
[/]
*=rw
@readonly=r
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn
mnanjala created the topic: Branch Managment in Subversion
How do you manage Subversion Branching and the per user role management?
rajeshkumar replied the topic: Re:Branch Managment in Subversion
Hi,
Can you redefine the questions. I may be able to help you out on this?
Regards,
Rajesh
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn
mnanjala replied the topic: Re:Branch Managment in Subversion
Sure, what is the best way of branching in Subversion,
-Pravin
rajeshkumar replied the topic: Re:Branch Managment in Subversion
Hi praveen,
you can find SVN (Subversion) Branching Strategy information in url below…
community.scmgalaxy.com/pg/blog/rajeshku…n-branching-strategy
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn
mnanjala replied the topic: Re:Branch Managment in Subversion
Thats Awsome and thanks Rajesh
-Pravin
Button replied the topic: Re:Branch Managment in Subversion
The problem with any branching approach, is how do you track what exactly has been merged into trunk, and what activity branches are contained in which tag etc. Check out agilescm, product from clearvision-cm, its pretty amazing and makes all of these tasks seemless, and its free for 10 or below users, see the link below
www.clearvision-cm.com/agilescm/overview
rajeshkumar replied the topic: Re:Branch Managment in Subversion
right now i am on Git. Will try soon 🙂
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn
pasupuleti2 created the topic: Migrating to BitBucket from Subversion
How to Migrate BitBucket from SVN? Please elaborate the steps.
Thanks
rajeshkumar replied the topic: Migrating to BitBucket from Subversion
This is the best tutorial i have come across for SVN to BitBucket migration….
www.atlassian.com/git/tutorials/migrating-overview/
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn
1. Subversion
2. GIT
4. Github
5. CVS
Our Subversion training courses are designed to provide the necessary hands-on experience to enable attendees to become productive immediately. We offer public classes at our training centers, private classes that can be held on-site at the customer’s location, as well as web based training.
Subversion user and administration training agenda as below;
Fundamental Concepts
Subversion in Action
Basic Usage
Basic Work Cycle
Examining History
Advanced Topics
Branching and Merging
Repository Administration
About us:
scmGalaxy online platform is a community initiatives based on Software configuration management and DevOps that helps members and organizations to optimize their software development process, advocating agile methodologies and improve productivity across all aspects of Application lifecycle management. We provide consulting, training and mentoring services in agile development practices such as Source Code Management, Continuous Integration, Build management, Test-Driven development, Acceptance-Test driven development, Build automation, code quality practices and automated testing and continuous delivery.
We provide job oriented training in the area of Software Configuration management, Build and Release Engineering and DevOps domain . Candidates with engineering or software background and looking to either start or change their career to Build and Release Engineering, would benefit most from this training. This course offered online around the globe which include India, USA, Europe, Australia, Bangalore, Delhi, Pune, Mumbai, Chennai and Hydrabad. Instructor is an expert in Software configuration management, Build and release engineering and DevOps with more than 10 years industry experience in India.
Course Objectives
To bring your team up to speed with agile development, We can also run the from Continuous Integration to Continuous Delivery with automated course within your premises.
Course Schedule
This course is an intensive 1-day & 2-day workshop with a mixture of teaching and lab exercises. Currently, this course is offered exclusively as an on-line course. Please contact us for more details.
Audience
This is a hands-on, practical course designed to teach specialized skills for real-world development situations. It is thus primarily aimed at a SCM Engineer, Build/Release Engineer, DevOps engineer and developer and QA audience.
Approach
The course is modular and flexible – depending on specific student needs and requests. Through our trainings, you benefit from the wide experience and architectural expertise of our team. We bring that experience to you in an highly interactive, intensely hands-on setting.
Assumptions
We assume participants have a reasonable understanding of Development in any language as well as a basic understanding of the Software Development Life Cycle.
Lab Work
All our courses are above all practical in nature. We believe that the best way to learn is by doing. So the course contains approximately 80% lab work.
Learning Resources
Each registrant will receive a copy of the student notes and lab solutions, a certificate of completion, and a CD containing all the tools covered in the course and CD containing all the tools covered in the course.
Contact Us
This course is provided on-site, and can be tailored to your particular requirements. If you would like our trainings delivered at your premises, or for any additional information please contact us. Please email us at info@scmGalaxy.com