Upload
others
View
7
Download
0
Embed Size (px)
Citation preview
1 Copyright ©2014 CollabNet, Inc. All Rights Reserved. ENTERPRISE CLOUD DEVELOPMENT
Subversion for Configuration Managers Best Practices
2 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Repository Layout
Branching & Merging
General Branching Principles
Branching Strategies
Nuances to Branching Models
Promotion Models
Managing Roles and Permissions
Configuring Autoprops and Ignores
Outline
3 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
• Every tool has things it does well and things it doesn’t do well
• There are fundamental expectations and requirements of a version control tool
• Knowledge of how the tool works and what users commonly need establish best practices
• Best practices are not the only way to do something, but they are the most commonly implemented way and a way that best utilizes the functionality of that tool
• Establish your requirements first (do not try to just port an existing process) and then identify the best practices that best satisfy those requirements
Best practices
4 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
• Do not expect to leave this training with your new processes defined
• Do not try to see how you map your existing process to Subversion best practices
• Do try to learn where best practices apply and do not apply
• Do try to understand why these are Subversion best practices
Goals of this discussion
5 Copyright ©2014 CollabNet, Inc. All Rights Reserved. 5 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Repository Structuring and Branching
6 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
• A new application may not mean a new repository (consider your organization’s repository best practices to determine when a new repository is needed)
• Have a consistent place for creating repositories to make back-ups easier (i.e., a single “mount” point)
• Be sure to implement repository access controls before granting any user access
Creating a repository
/ trunk/ tags/ branches/
/ application-a/ trunk/ tags/ branches/ application-b/ trunk/ tags/ branches/ application-c/ trunk/ tags/ branches/
7 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
What drives repository structure?
• Remember that branches and tags are not meta data in Subversion, but instead paths or folders themselves
• Remember that you need to be use branches and tags so that you (and others) will be able to understand that a path is a branch or tag
• Remember that you need to be able to easily find branches or tags
• Therefore, the structure of your repository needs to not only consider the folders and files you want to control, but also the locations of branches, tags, and the trunk
8 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
What goes where?
• Best practice: branch at a single level, e.g.
• In other words, every branch contains a version of the complete application structure at the same level
– Subversion will handle multiple levels fine but humans lose track
– No need to try to ‘optimize’ – Subversion’s copy is a constant time and space operation
Additional best practice:
• They should be grouped by life-cycle. In other words, define at what level to release and group accordingly.
/ branches/ tags/ trunk/
9 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
• One repository per application:
Repository layout
Each repository has a: • Single revision range • Single set of hook scripts • Single authentication & authorization
realm
• Multiple applications in a single repository:
/
application-a/
trunk/
tags/
branches/
application-b/
trunk/
tags/
branches/
application-c/
trunk/
tags/
branches/
/ trunk/ tags/ branches/
/ application-a/ trunk/ tags/ branches/ application-b/ trunk/ tags/ branches/ application-c/ trunk/ tags/ branches/ …
10 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
If a larger product is actually a composite of selected releases of individually deliverable sub-products, then a repository structure that allows for easy identification of what sub-product versions make up the larger product version is recommended.
System of systems
/tags /product-a /branches /tags /trunk /product-b /branches /tags /trunk /product-c /branches /tags /trunk …
11 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
• You can structure branches and tags – Ex: copy /trunk/ into /branches/1.0/
• For example (underlined directories exist merely for the structuring of tags): – A single main line
– Release branches and tags
– Snapshot and release tags to enable a patching model
• Always stick to a single level in the data tree at which you branch and tag
Structuring branches and tags
/ branches/ 1.0/ 1.1/ 2.0/ tags/ releases/ 1.0/ 1.1/ snapshots/ 1.0/ 20061209/ 20070210/ 1.1/ 20070117/ trunk/
12 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
• The most frequent requirement for establishing a substructure under branches and tags is a clear identification of a need for users to have the ability to use these concepts for reasons outside of the formal process.
• There are no consistent best practices use cases for establishing developer controlled branches and tags.
• However, if there is a desire to have developer controlled branches and tags, then there is a need for defining access differently which is greatly assisted by the use of substructures:
Structuring branches and tags for access control
/ branches/ dev/ SCM/ tags/ dev/ SCM/ trunk/
13 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
• The contents of a working copy shouldn’t have to reflect the exact structure of a single repository for several reasons including: – Shared components – Commercial off-the-shelf (COTS) products/tools – Role-specific repositories (e.g., testing, database, documentation,
requirements)
• Subversion supports this through a property, svn:externals, which allows you to map into a working copy folder to a folder elsewhere in that repository or another one; or to map a file to a file elsewhere in that repository.
Working copy layout can be different from repository layout
14 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Map a file in one project to a working copy file path in another project within the same repository.
– On https://repo1/PROJECT1/trunk set the svn:externals property
svn propset svn:externals “../../PROJECT2/trunk/readme@7654 readme2” ..
Externals example 1
15 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Map directory in one project into a working copy directory path in another project in a second repository
– On https://repo1/PROJECT1/trunk set the svn:externals property
svn propset svn:externals “https://repo2/PROJECT1/tags/ver1.0 project2” .
Externals example 2
16 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
• Externals can point to: – Directories - either within the same or a different repository. – Files - only within the same repository.
• Subversion operates only partially on disjointed working copies: – Paths created via an externals definition are disconnected from the
primary working copy (on whose versioned directories the svn:externals property was actually set).
– Read based operations (e.g., update, checkout, export, and status) will recurse into a part of a working copy that has been created via an external.
– Write based operations, like commit, will not work if the external involves a different repository.
• For that case, write based operations will require navigating to the externally mapped directory or file.
Externals limitations
17 Copyright ©2014 CollabNet, Inc. All Rights Reserved. 17 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Branching and Merging
18 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Importance of branching and merging
• No topic is viewed as more critical to configuration management
• Appropriate branching supports the need for isolation without adding unnecessary complexity from excessive merging
• Nothing will have a greater impact on user satisfaction or dissatisfaction with Subversion
• This area of best practices is critical, yet can be very simple
19 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Branch creation – best practices
• General use branches should be created by a defined role (e.g., lead developer or configuration manager)
• While a role should be assigned responsibility to create branches, it is best left as a policy rather than trying to set access control to enforce it
• Branches should be created directly in the repository versus being created in a working copy and committed from there
20 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Branch and tag nomenclature
• Name should not duplicate information already in the path – Path will already include the fact that it is a branch or tag – Path will already indicate the larger project that is being branched or tagged
• Names should provide sufficient information on purpose and scope – Purpose should either be indicated by the hierarchy (i.e., ancestor folder
naming) or in the name (e.g., release, feature) – Scope should also either be indicated by the hierarchy or in the name (e.g.,
release_1.0, feature_artf12345)
• Names should be written concisely as they will be entered by users – Clear abbreviations or acronyms are good if understood easily (e.g., def, enh) – Words should be truncated once there is enough characters to easily understand
them (e.g., req, feat)
21 Copyright ©2014 CollabNet, Inc. All Rights Reserved. 21 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
General Branching Principles
22 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Know when to branch
• The Never-Branch Approach – Users commit their day-to-day work on /trunk
• The Always-Branch Approach – Each user creates/works on a private branch for every coding task
– When coding is complete, someone merges the changes to /trunk
• The Branch Based on Need Approach – Branches created for long term development
– When coding is complete, someone merges the changes to the appropriate parent branch
23 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Know when to merge
• Merge as often as feasible – Isolation can be useful, but don’t let it last too long – Avoid the big hit if you wait and get a myriad of other’s changes late in your
development effort – The smaller the two ranges of change sets involved, the smaller the chance of
conflicts – Tree conflicts are particularly time consuming so merge refactors as soon as
possible
• Merge to close out a branch
• Merge at key milestones – Production releases – Service pack releases
24 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
General principles for branching and merging
• Branches are to isolate work, not increase silos
• Configuration management processes should have no more complexity than absolutely required (KISS)
• Branches should not be an alternate for tagging
System version branch
APP 1.0.0
TRUNK
Release branch
APP 1.0.1
25 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
General principles for branching and merging, cont’d
• Branches should have: – A logical start
– Expected content
– Consistent merges
– A logical end
• Merge as often as feasible
System version branch
APP 1.0.0 TRUNK
Task branch
APP 1.0.1
Bugfix branch
System version branch
26 Copyright ©2014 CollabNet, Inc. All Rights Reserved. 26 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Branching Strategies
27 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Basic branching strategies
• Unstable Trunk – serial release model
• Stable Trunk – parallel release model
• Agile Release - delayed release definition model
• Questions to answer: – When do you branch and merge?
– What is on each branch?
– Use cases
28 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
• When to branch: – At the feature complete point for release branches
– At the point work needs isolated from general development
• When to merge: – At the commit point for inclusion in the next release
– At release points for both production and bug fix releases
Unstable trunk
Isolated development
APP 1.0.0
TRUNK
Release branch
APP 1.0.1
29 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
• What’s on the branch – Trunk - ongoing development of next general release
– Release branches - formal promotion process
– Isolated development branches - work that is either experimental or not accepted for inclusion in the next release or causes risk
• Use cases – Waterfall, serial development (e.g., Subversion itself)
– Single customer with small team (e.g., internal infrastructure projects)
Unstable trunk, cont’d
Isolated development
APP 1.0.0
TRUNK
Release branch
APP 1.0.1
30 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
• When to branch: – At the release definition point for release branches
– At the point work needs isolated from general development
• When to merge: – At the start of release branches
– At the release points both production and bug fix releases
Stable trunk
Release branch
APP 1.0.0 TRUNK
Task branch
APP 1.0.1
Bugfix branch
Release branch
31 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
• What’s on the branch – Trunk – stable points of releases – Release branches - reflect release development process including formal
promotion process (to some extent they are the “trunk” of that release) – Task branches - work that has long periods of instability
• Use cases – Waterfall, overlapping development (e.g., most major software
products) – Larger teams
Stable trunk, cont’d
Release branch
APP 1.0.0 TRUNK
Task branch
APP 1.0.1
Bugfix branch
Release branch
32 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
• Cascading merging with the stable trunk model is recommended: – Following the best practice of merging frequently – In recognition of the common problem of bugs reappearing in later releases – In order to plan for merging between branches rather than handling it ad hoc – When the release order is known
• The general concept of cascading merges is that each release periodically merges in the work done on the release that will proceed it into production. The exception is that the next release to be made periodically merges in production changes either from trunk or from the bugfix branch of the current production release.
Cascade merges with the stable trunk
Release branch 1.0.0
APP 1.0.0 TRUNK
Release branch 1.1.0
Release branch 1.2.0
33 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
• When to branch: – At the release definition point for release branches
– At the task definition point for clear units of work
• When to merge: – At the definition of releases
– At release points both production and bug fix releases
Agile release
TRUNK
Task branch
Release branch
Task branch
Task branch Task branch
APP 1.0.0 APP 1.0.1
34 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
• What’s on the branch – Trunk – stable points of releases and bug fixes – Release branches – reflect release development process, primarily the
formal promotion process – Task branches – definable units of work
• Use cases – Agile development and release (e.g., Internet applications)
Agile release, cont’d
TRUNK
Task branch
Release branch
Task branch
Task branch Task branch
APP 1.0.0 APP 1.0.1
35 Copyright ©2014 CollabNet, Inc. All Rights Reserved. 35 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Nuances to Branching Models
36 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Feature branch
• Allows work on a feature to be isolated from other work and also allows work to be committed that might break builds for others
• Provides a means of mitigating the risk of committing work on a feature that might later be deleted from this release
• Provides flexibility if a feature needs to be accelerated or delayed into a different release
Release branch
APP 1.0.0 TRUNK
Feature branch
Release branch
37 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Team branch
• Allows for work to be broken into big logical units worked by teams without their commits impacting non-team members (much like feature branches)
• Provides for collaboration while isolating risk
• Still permits the other types of branches will talk about in the next few slides
Release branch
APP 1.0.0 TRUNK
Team branch
Release branch
38 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Developer branch
NOTE It is possible to select local as well as LDAP authentication. If both authentication methods are enabled, usually local authentication is tried first, and then LDAP authentication, but it is configurable.
NOTE
• Not a best practice as these are unmanaged and generic branches
• Best practice is to use feature branches instead
• Most common justification is to either allow for commits that would otherwise break builds or not be made (thus introducing risk of loss) or to handle experimental work which we will look at in a bit
APP 1.0.0 TRUNK
Release branch
Release branch
Bob branch
39 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
• Work is not only not assigned to a particular release, but is not guaranteed to ever be released
• End point would either be a merge (full or partial) into the release branch that will be the method of its release or just an unceremonious stoppage or deletion
• Many times work here is merely not assigned to a release as it is known that it will take longer than a normal release cycle, e.g., merge tracking in Subversion
Experimental branch
APP 1.0.0 TRUNK
Release branch
Release branch
Experimental branch
40 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
• No definite end point
• No requirement to take each production release
• Needed to hold customizations
• Potentially may contribute changes to the core product
• Can be used for internal customers just as easily as external ones
Customer branch
Release branch
APP 1.0.0 TRUNK
Customer branch
Release branch
CUSAPP 1.0.0
41 Copyright ©2014 CollabNet, Inc. All Rights Reserved. 41 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Merging Concepts and Best Practices
42 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Repeated merge: – Much like the use of the update command, keeps a dependent line of
development up-to-date with its parent branch
Merge use cases – repeated merge
svn:mergeinfo trunk:11-21
svn merge http://path_to_repo/trunk .
11
14 18 16
10
12
13
15
17 20 /trunk 21
WORKING COPY
19
WORKING COPY
/branches/somebranch
43 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Transitive merge: – A positive benefit inherent to Subversion when merging is happening
across multiple branches, but isn’t derived from a specific branching and merging use case
Merge use Case – transitive merge
43
Trunk
11
BranchA
12
13
BranchC
BranchB
14
16 18
15
17 19
svn:mergeinfo /branches/BranchA:12-15
20
WORKING COPY svn merge http://path_to_repo/branches/BranchA .
WORKING COPY
21
svn merge http://path_to_repo/branches/BranchB .
svn:mergeinfo /branches/BranchA:12-15 /branches/BranchB:14-20
WORKING COPY
WORKING COPY svn merge http://path_to_repo/branches/BranchA .
22 23
24
svn:mergeinfo /branches/BranchA:12-23 /branches/BranchB:14-20
44 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Cherry picking: – Applies most commonly when bugs are identified that need to be
applied to other release branches – Can be used to selectively apply features or enhancements from one
branch to another (e.g., a custom feature developed for a customer is merged into the general product development to be available to all customers)
Merge use case – cherry picking
44
Trunk
11
BranchA
12 14
13 15 16 17
18
WORKING COPY
svn:mergeinfo /trunk:15
svn merge –r 13:15 http://path_to_repo/trunk .
45 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Parent and Child: – Ability to merge a child back into its parent when the work on it is
complete where it has been continually updated with changes from its parent
Merge use case – parent and child
45
Trunk
11
BranchA
12 14 16
13 15
17 20
18 19
svn:mergeinfo /trunk:11-15
svn:mergeinfo /trunk:11-19
svn:mergeinfo /branches/BranchA:12-21
WORKING COPY
svn merge http://path_to_repo/branches/BranchA .
21
22
46 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Record manual merge: – Supports the ability to log merges that had to be done manually so that they are
documented
– Supports the ability to block a revision from being merged to a specific branch while allowing for the ability to remove that block if the situation changes
Merge use case – manual (record-only) merge
46
Trunk
11
BranchA
12 13 14
15
WORKING COPY
svn:mergeinfo /branches/BranchA:14
svn merge –c 14 –record-only http://path_to_repo/branches/BranchA .
47 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Rollback merge: – Work is found to be faulty, incomplete or determined not to be included
in that development effort
Merge use case – rollback merge
47
Trunk
11
BranchA
12 15
13 14
+
svn:mergeinfo /trunk:13-14
+ - 16
WORKING COPY
svn merge –r 15:12 http://path_to_repo/branches/BranchA .
There is no longer mergeinfo associated with this branch
48 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Merging best practices
• Do not have local, uncommitted changes in your working copy prior to a merge action.
• Avoid mixed revisions or switched children in the working copy (now blocked by Subversion).
• Point your working copy at HEAD for the line of development to which you are merging.
• Identify a merge with the source path in your commit message (the revisions can be determined through a diff of svn:mergeinfo values).
• After merging, use status and diff for sanity check.
• Build and run unit tests before committing.
49 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Merge auditing: – Merge data automatically added to svn:mergeinfo – Reports merge data using the mergeinfo operation
Merge auditing
49
Trunk
11
BranchA
12 14
15 16 18 13
17
WORKING COPY
svn:mergeinfo /trunk:15
svn merge –c 15 http://path_to_repo/trunk .
50 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Auditing
• Property (svn:mergeinfo) set on files and directories to record all merge information (be sure to include it in the commit)
• Merge history discovery – Branches remember their origins.
– mergeinfo operation provides answers to the questions: • What changes have I merged into a branch? • What changes are eligible for merge into a branch?
• Traceability – By recording what revisions exist on what paths, Subversion provides traceability of what
changes made it where – Automation is key to ensure the information is consistent and reliable – Via a switch --use-merge-history (single-character shortcut -g) – log -g: shows what changes were merged by a commit – blame -g: shows the original committer and revision for each line in a file
51 Copyright ©2014 CollabNet, Inc. All Rights Reserved. 51 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Promotion Model and Tags
52 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
What is a promotion model?
• Most development has a process that defines steps that are to be taken between the end of day-to-day development and the declaration of a production version. The process is their promotion model.
• Promotion models can have very discrete phases/stages or they can basically be “black boxes.”
• Understanding historically what was put into a phase, when it was put there, how long spent between phases, or how many candidates for a phase were required can be invaluable data (waiting for the question to start collecting the data is too late)
• The promotion model should be traced in version control and arguably is as valuable if not more valuable than the day to day control of revisions.
53 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Tagging the promotion model
• Allows visibility to the promotion process
• Allows metrics to be gathered around the promotion process
• Makes it easy to diff releases as well as promotion stages
• Not useful if information around them is of fleeting interest
Release branch
TRUNK
Release Candidate 1
PRODUCTION
Release Candidate 2
Release Candidate 3
54 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
• Formal tags should be created by a defined role (e.g., lead developer or configuration manager)
• While a role should be assigned responsibility to create tags, it is best to enforce it only by limiting who has write permissions to that area of the repository versus implementing true immutability
• Tags should be created directly in the repository versus being created in a working copy and committed from there
Tag creation – best practices
55 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
When to tag
Two choices – before or after the build (or whatever process creates a testable output)
• Before build: – Can identify issues with the handoff (i.e., use a counter) – Guarantees that what’s tagged is what was built against – Does mean more tags that are not being used
• After build: – No idea how many times build attempted since only the successful
are tagged – Has more potential that the tagged source could differ from what
was used to build the binaries – No extraneous tags
56 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Promotional models
Release branch
TRUNK
Beta 2 Alpha 2 Beta 1 Alpha 1
PRODUCTION
Release branch
TRUNK
Release Candidate 1
PRODUCTION
Release Candidate 2
Release Candidate 3
Release branch
TRUNK
QA4 UAT2
QA2 QA3 UAT1
QA1
PRODUCTION
57 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Promotional model metrics
• How many builds are required before there is a successful pass-off from development to a release engineer?
• What files or modules are causing the most issues in getting through a promotion model?
• How long does it take to get through a specific phase/stage of the promotion model?
• How many candidates for a specific phase/stage are required before that phase is successfully passed?
• Where can we improve a promotion model?
• How long do we think it will take to get a future release out?
58 Copyright ©2014 CollabNet, Inc. All Rights Reserved. 58 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Managing Roles and Permissions
59 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Importance of securing subversion
• Software is not a sideline business for your enterprise
• If you secure other assets, then you should secure your code
• Accidents and malicious acts happen, do not react, but instead be proactive
60 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
The two aspects of security
• Authentication – confirm who you are (handled by a system administrator)
• Authorization – confirm what you are allowed to do (handled by a configuration manager)
61 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Authorization – read permission
Open source principle:
Assume read rights for all and define the exceptions
– Non-employee access
– Access to critical systems
– Access to critical files
– Access to new products
62 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Authorization – write permission
Write permissions – commonly limited to some extent
– Non-developer resources
– Non-employee resources
63 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Different levels of access control to be considered:
• Repository (often by role, platform, business, etc.)
• Branch (often for stability)
• Directories (often by role)
• Files (special cases)
• Tags (simple immutability)
Write permission granularity
64 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
• Do not go to this level unless necessary
• Do not use beyond the rules truly required
• Do not set rules to monitor exceptions Visibility and the ability to “undo” are a better answer
• Do not relax security purely over performance concerns
Path-based access control considerations
65 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Means writing a script/program to further control user access based on more complex rules.
• Pros: – More granularity (e.g. add vs. modify vs. delete vs. copy) – Unique to your organization
• Cons: – Maintenance – Potential trade-offs (like any hook)
• Performance • Security • Reliability • Scalability
Hook extensions?
66 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
• To the extent possible (e.g., repository access) grant read rights to everyone
• Limit write access by: – Branches (e.g., trunk may have only a specific group/role with write
permission) – Directories (e.g., QA directory may have a specific group/role with write
permissions) – Tags (e.g., formal tags may only be created by specific group/role)
• Users can be in more than one group so cumulative access rights
• Users can have different rights on different projects/repositories
Define roles by read and write access limits
67 Copyright ©2014 CollabNet, Inc. All Rights Reserved. 67 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Configuring Autoprops and Ignores
68 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
• Versioned properties enable you to store meta data against versioned objects but require that the property be set on relevant paths.
• Required (based on your organization’s process) properties, if manually applied, can easily be forgotten or the value associated incorrect.
• Upon add or import, Subversion runs a basic heuristic to determine whether a file should have properties set on it based on either a set svn:auto-props property or a client/server configuration file.
• Auto props is a configurable option set either on the server or the client via a property or a configuration file.
– The property svn:auto-props can be set on any folder at or above the folder in which a file is being added (via add or import) which sets pattern and property assignments.
– There is a single config file on a Subversion server which sets the default values for the settings contained within it.
– Each user has a config file which overrides the server file.
Automatic property setting
69 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Subversion uses the file pattern syntaxes most commonly found in Unix systems implemented on those systems as the fnmatch system function. It supports the following wildcards:
• ? – Matches any single character Chapter_00?.doc would match Chapter_001.doc through Chapter_009.doc, but not Chapter_010.doc or Chapter_0010.doc
• * – Matches any string of characters including the empty string *.c would match any file ending with an extension of .c including one called just .c
• [ – Begins a character class definition which will be terminated by a ], used for matching a subset of characters [a,b,c].txt would match a.txt, b.txt, and c.txt, but not any other file names
File patterns
70 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
• Set the svn:auto-props property on a folder to automatically map a filename pattern to a versioned property key-value pair.
Or
• Configure auto-props in your run-time configuration to do the same.
– Turn on by setting enable-auto-props to yes.
• For either, set one line per pattern to PATTERN = PROPNAME=PROPVALUE[; PROPNAME=PROPVALUE].
Automatic property setting, cont’d
[miscellany] enable-auto-props=yes [auto-props] *.c = svn:keywords=Id *.jpg = svn:needs-lock=*
$ svn propget svn:auto-props --show-inherited-props -v calc Inherited properties on 'calc', from 'http://svn.example.com/repos': svn:auto-props *.c = svn:keywords=ID *.jpg = svn:needs-lock=*
71 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
• Almost without exception, the best practice approach would be the use of the svn:auto-props property which best guarantees uniformity and consistency.
• You should apply the property at the topmost folder where you want the tree to apply the property.
• You can apply the property with additional patterns in other subfolders which will be appended to the value inherited from parent folders.
• Users can still employ their local configuration file for additional patterns unique to them, but the svn:auto-props rules override the local ones for the same pattern.
• A pattern set on a folder overrides any rule set on that pattern that was inherited (they are not concatenated).
* Notes: ONLY a 1.8+ client understands the svn:auto-props property; a user can provide the --no-auto-props option when adding or importing
Best practices for automatically applying properties
72 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
What is meant by ignoring files?
– Normally, Subversion refers to files that are not under its control, but present in a working copy as unversioned files. At times, these files will be presented with the explicit or implicit suggestion they should be added to the repository.
– If files are identified (by pattern) to be ignored, they fall in a different
category (i.e., ignored files) for Subversion and are not presented. – It does not mean these files cannot be added to version control, but
rather that they are not assumed to be candidates for control and would have to be explicitly added.
Ignoring files
73 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
There are three available means by which to ignore files by extension:
– Use the svn:ignores property on a folder – this allows for files to be ignored within the folder upon which the property is set, but only within that folder
– Use the svn:global-ignores property on a folder – this allows for files to be ignored within the full tree structure represented by the folder upon which the property is set, but only within that repository and structure
– Use the global-ignores configuration setting – this allows for files to be ignored in every folder in every working copy on the machine where the configuration file exists (a server configuration file will only impact the user machines if the user machines have nothing set in their own configuration file)
Ways to ignore files
74 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
• Set the svn:global-ignores property on a folder to automatically map a filename pattern to a versioned property key-value pair.
Or
• Configure global-ignores in your run-time configuration to do the same.
* Notes: ONLY a 1.8+ client understands the svn:global-ignores property; if both the property and run-time configuration have been set, then the applied list is the superset of both (and if svn:ignores is set on a folder, then the list includes those defined for it as well, but just for that folder).
Setting file ignores
[miscellany] global-ignores = *.obj *.tmp
$ svn propget svn:global-ignores --show-inherited-props -v calc Inherited properties on 'calc', from 'http://svn.example.com/repos': svn:global-ignores *.obj *.tmp
75 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
• If your need is local to a single folder, then use the svn:ignores property.
• If your need is specific to a repository or to an application within a repository, then use the svn:global-ignores property.
• If your need is multi-repository, you can either: – Try to implement a global ignores process using the configuration file by
either propagating a standard configuration file or establishing the global ignores on the server and forbiding users from doing anything with that setting locally.
Or – Take a standard approach to establishing repositories that not only requires
the setting up of a default folder structure to handle branches, tags, and trunk, but also requires setting the svn:global-ignores property on the top level folder.
• Using both approaches is fine as well since a superset would be the result rather than one approach overriding the other.
Best practices for ignoring files
76 Copyright ©2014 CollabNet, Inc. All Rights Reserved. 76 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
Thank You
77 Copyright ©2014 CollabNet, Inc. All Rights Reserved. 77 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
About CollabNet
CollabNet is a leading provider of Enterprise Cloud Development and Agile ALM products and services for software-driven organizations. With more than 10,000 global customers, the company provides a suite of platforms and services to address three major trends disrupting the software industry: Agile, DevOps and hybrid cloud development. Its CloudForge™ development-Platform-as-a-Service (dPaaS) enables cloud development through a flexible platform that is team friendly, enterprise ready and integrated to support leading third party tools. The CollabNet TeamForge® ALM, ScrumWorks® Pro project management and SubversionEdge source code management platforms can be deployed separately or together, in the cloud or on-premise. CollabNet complements its technical offerings with industry leading consulting and training services for Agile and cloud development transformations. Many CollabNet customers improve productivity by as much as 70 percent, while reducing costs by 80 percent.
For more information, please visit www.collab.net.
78 Copyright ©2014 CollabNet, Inc. All Rights Reserved. 78 Copyright ©2014 CollabNet, Inc. All Rights Reserved.
© 2014 CollabNet, Inc., All rights reserved. CollabNet is a trademark or registered trademark of CollabNet Inc., in the US and other countries. All other trademarks, brand names, or product names belong to their respective holders.
CollabNet, Inc. 4000 Shoreline Court Suite 300 South San Francisco, CA 94080 USA www.collab.net +1-650-228-2500 +1-888-778-9793 blogs.collab.net twitter.com/collabnet www.facebook.com/collabnet www.linkedin.com/company/collabnet-inc