I am brand new at sub-versioning, so please bear with me.
I use CollabNet's Subversion Edge to manage a repository for a PHP/ActionScript based project I am building in the Eclipse IDE. In my project's root folder, Eclipse included several configuration files that aren't directly related to the project. How can I set up my repository to ignore these files/folders via CollabNet? Would it be through the "Repository Access Rules"?
Thank you for your time.
The "Chapter 3. Advanced Topics 'Ignoring Unversioned Items'" seems appropriate for your setup:
Extract:
[...] But these not-to-be-versioned files and directories can cause some annoyance for Subversion users.
For example, because the svn add and svn import commands act recursively by default, and don't know which files in a given tree you do and don't wish to version, it's easy to accidentally add stuff to version control that you didn't mean to.
And because svn status reports, by default, every item of interest in a working copy–including unversioned files and directories–its output can get quite noisy where many of these things exist.
So Subversion provides two ways for telling it which files you would prefer that it simply disregard.
One of the ways involves the use of Subversion's runtime configuration system (see the section called “Runtime Configuration Area”), and therefore applies to all the Subversion operations which make use of that runtime configuration, generally those performed on a particular computer, or by a particular user of a computer.
The other way makes use of Subversion's directory property support, is more tightly bound to the versioned tree itself, and therefore affects everyone who has a working copy of that tree. Both of the mechanisms use file patterns.
The Subversion runtime configuration system provides an option, global-ignores, whose value is a whitespace-delimited collection of file patterns (also known as globs).
The Subversion client checks these patterns against the names of the files which are candidates for addition to version control, as well as to unversioned files which the svn status command notices.
If any file's name matches one of the patterns, Subversion will basically act as if the file didn't exist at all.
This is really useful for the kinds of files that you almost never want to version, such as editor backup files like Emacs' *~ and .*~ files
Related
I'm working on a symfony 2 web site, it is a product our company sells (every client gets his own installation).
Each of our client gets a slightly different version of the site: sometimes the differences are small (different strings, slightly different templates), and sometimes they are bigger (different bundles activated, different database schema, different security.yml file etc.)
Currently each version sits on its own git branch. This works for now as we only started selling and don't have many clients(=branches) yet.
But I want to move to a better solution.
Any ideas?
Thanks,
A
I disagree. If it's a single application, then branches per client or release, ie configurations that need separate histories (change tracking), are precisely the correct practice. Clients use/share the same app, "core", whatever, but possibly you want to control when changes in one client's features/bugs are merged into the other configurations, ie branches. Each client will have to be "upgraded" by merging from the development branch to client's branch, separately, manually. You want to pay this overhead to gain stability and isolation.
As for the specific differences you mentioned:
Different strings: client specific configs, constants, deployment stuff, should probably be in a per-client/deployment module (include file, whatever), that you can simply ignore when merging, so that the core app code will have no client/deployment specific differences, ever.
Slightly different templates: meh, this smells bad; if you can use symbolic constants or partials or whatever, and move the differences to a config.php, then see the above solution. Otherwise, don't template diffs suggest it's not the same app anymore?
Different bundles activated: if you can put the include statements in the config.php, no problem.
Different database schema: nasty business. Can this app be made schema-independent? Can you do polymorphism somehow? Nu, I don't know, haven't touched PHP in twenty years, I only do CoffeeScript and NoSQL now. ;o)
Different security.yml: same as with config.php, not a problem, just don't merge that file, or even stop tracking it (remove from repo) altogether.
HTH.
;o)
I don't think that a branch is a good solution as its not intended for this kind of use case. As i see it, branches should be used for a staging or features/fixes.
As i see it, you have few options (in case you are not familiar with those options, you should read more about them in the links i attached):
Git submodule. "A submodule allows you to keep another Git repository in a subdirectory of your repository. The other repository has its own history, which does not interfere with the history of the current repository. This can be used to have external dependencies such as third party libraries for example." http://git-scm.com/docs/git-submodule
Composer. This is what i think would best suite you. Use a regular dependencies manager (composer for php, npm for nodejs etc..). I will give you full control over the version been used + easy deployment options. https://getcomposer.org/
Another option would to do it "old school".. In case they are all in the same server, just keep the "Core" stuff in the root folder and include it for each project. It's no a recommended way to go but it might be enough and won't require much changes from you
Our current development setup uses a single Subversion repository containing multiple projects, each with branches, tags, and trunk. We then use a "sparse checkout" to select the projects, and branches of those projects, to work with.
The result is that the directory structure of a working copy matches that of the repository, including branch information, and we never use svn switch. (This style of working will probably be familiar to anyone who uses SVN, but may be surprising to those who don't.)
We are thinking of using Composer to manage both external and internal dependencies, but I'm not sure how this can work with the sparse checkout style of working.
I would like some way of using a directory within the existing checkout to satisfy a dependency, rather than each "root project" needing a separate copy.
For example:
sites/Foo/trunk
depends on lib Aaa, so references lib/Aaa/trunk
depends on lib Bbb 1.5.*, so references lib/Bbb/branches/release-1.5
sites/Bar/trunk
depends on lib Aaa 1.0.*, so references lib/Aaa/branches/release-1.0
depends on lib Bbb 1.5.*, so references lib/Bbb/branches/release-1.5
At present, if I edit the code in lib/Bbb/branches/release-1.5, I can test those changes on both sites, without needing to commit one and update the other.
Is there any way of using Composer to manage these dependencies?
(PS: Please don't answer with "give up on SVN, use Git, it is teh awesomez"; that is an answer to a different question.)
No - I do not believe that you can do this with Composer as standard: it expects to copy the files from whichever source (Packagist/VCS/Zips) to the local vendor folder, which is not what you want.
That said, I believe there are two potential ways you could get this working (at least in part):
Autoloader
You could try using the autoload field in the composer.json file to include the correct files into the project. You would still need to manage the checkouts of the relevant branches/versions manually (like I assume you do now), but you would be able to manage the inclusion of the internal libraries through Composer. This will probably require that your libraries are properly namespaced. The paths to the files for each namespace are relative to the root of the project, but can go below the root (via the /../ path) if required.
To be honest though, if you already have an autoloader for these files, there may not be much advantage to this solution. Relevant Docs
Composer Plugin
You could also write a composer plugin/"custom installer" that could probably manage this. This would have the advantage that you could have it manage checking out the correct parts of the sparse repository to have the correct version available, as well as doing correct wildstar version checking, but would be a much more difficult and riskier venture.
The basic process would be that you would define a new package type (e.g. 'internal-svn-package'). You would create the plugin as an external library that gets installed normally via Composer, which declares (via it's composer.json) that it handles this new type of package. Your custom logic would then be used for any packages that are listed with this custom type. I'm not sure how much of the internal composer logic for SVN checkouts you would be able to reuse however. Relevant Docs
I have been looking into incorporating an asset management/pipelining tool (probably Assetic) into my PHP project.
Since assets can be grouped into collections or wildcard-based paths using such tools, if I wanted to set up a watch process that re-compiled/minified only those source files that had changed, how would I do that given that assets have to be looked up by name (see example below)?
(I noticed that for Symfony there's a watch task for Assetic but I'm not sure that it re-compiles only the changed file(s) and also I would have to make it work outside of Symfony since my app uses the CodeIgniter framework.)
In Assetic, you can create a wildcard-based asset, e.g.:
new GlobAsset('/path/to/compass-sources/*')
You can tell it to send the assets through a filter (Compass in this example) and then output the result (CSS) to a folder like public/css.
Let's say I set up the watch process using node.js's fs.watch so that I can theoretically tell Assetic to re-compile a particular asset whenever one of its source files changes.
Since my node.js script would only know the name of the actual file that changed (e.g. compass-sources/layout.scss), how could I look up which AssetCollection or GlobAsset that particular file belonged to (say an asset called global-styles) in order to recompile it?
I'm open to alternatives here. I looked at grunt and may very well use grunt-contrib-watch to handle the file watching, but I like the idea of using Assetic because the project is in PHP and I think that will be easier on future PHP developers working on the system who may not be familiar with node.js. It seems grunt take a different approach where assets don't necessarily go in named bundles. Mostly I want to understand the conceptual approach of named asset bundles (like in Assetic) as it relates to my goal of recompiling assets whenever the source files change.
What is a benefit of having "build/" folder where all the sources will be placed and "built"?
Maybe it's a silly question, but I'm trying to understand Continuous Integration with PHP. Any example of build.xml for phing uses such build/ folder, but what's a sense in that for PHP where a checked out project doesn't require a compilation, only a basic configuration. Copying it all into build/ will just complicate the things, because you'll have doubled files and +1 folder to the web root path (if you'd like to have web UI to run selenium tests on)
Particularly I need phing for two cases:
1) let new user setup his first installation (or update old), right on a working copy
2) run unit/func-tests, phpcc, phpcs, phpdoc etc (all that usually on CI server)
Should I have "build/" for the second task? What is the best practice for PHP?
There are several good reasons to have a build directory (i.e., deployment to multiple environments, performing some text replacement, minimizing and combining CSS and JS, optimizing images, handling of config files etc.)
However, these may not apply in your use cases. There is no rule saying you need this directory. Depending on your thinking on testing in production, a build directory may be a good reason to keep this directory.
I have a folder of PHP scripts, they are mostly utility scripts. How to share those scripts among different PHP applications so that reuse and deployment are easy?
I would have to package my app into an installer, and let the user install it.
I could put the lib and hardcode the include path, but that means I haven to change the PHP code every time i deploy the web application to a new customer. This is not desirable.
Another route I consider is to copy the lib to other apps, but still, since the lib is constantly updating, that means that I need to constantly do the copying, and this will introduce a lot of problems. I want an automated way to do this.
Edit: Some of the applications are Symfony, some are not.
You could create a PEAR package.
See Easy PEAR Package Creation for more information on how to do this.
This assumes that when you say anyone, you mean outside your immediate organisation.
Updated: You do not need to upload to a website to install the PEAR package. Just extract your archive into the pear folder to use in a PHP application.
Added: Why not create a new SVN repository for your library? Lets say you create a library called FOO. Inside the repostory you could use the folder heirachy of trunk\lib\foo. Your modules could then go into trunk\lib\foo\modules and have a file called trunk\lib\foo\libfoo.php. Now libfoo.php can include once or require once all the modules as required.
PHP now supports Phar archives. There's full documentation on php.net.
There's a complete tutorial on IBM website as well.
One neat thing you can do with Phar archives is package an entire application and distribute it that way.
http://php.net/phar
http://www.ibm.com/developerworks/opensource/library/os-php-5.3new4/index.html
Ahh, libraries...
There are two conflicting purposes here:
Sanity when updating scripts (ie. not breaking 10 other apps).
Keeping things in one organized logical place for developer efficiency.
I suggest you take a close look at git and git submodules
We use git submodules extensively for this very purpose. It allows the best of both worlds because shared scripts can be upgraded at will in any project, and then that change can be moved to the other projects (deliberately) when you have time to do so and test correctly.
Of course, you need to be using git to take advantage of submodules, but if you are not using git, and you start, you'll eventually wonder how you ever lived without it.
Edit: Since the original poster is using svn, consider using SVN Externals.
UPDATED:
you just have to put the lib in some place reachable by your apps (in a place where you can reach it via http or ftp or https or something else) and include it.
If you have to update it often you can package your library in a single phar file and you can then provide your client a function to pull the library from some remote path and update a parameter in their local configuration accordingly, like:
function updateLocalLibary(){
//read the remote library in a variable
$file= file_get_content($remoteLibraryRepository.$libraryPharFile);
//give it a unique name
$newLibraryName=$libraryPharFile."_".date('Ymdhsi');
//store the library it on a local file
file_put_content($localLibraryPath.$newLibraryName,$file);
//update the configuration, letting your app point to the new library
updateLatestLibraryPathInConfig($newLibraryName);
//possibly delete the old lib
}
In your include path then you don't have necesasrily to hardcode a path, you can include a parameter based on your config, like:
include( getLatestLibraryPathFromConfig() )
(you are responsible to secure the retrieval in order to let only your clients see the library)
Your conf can be in a db, so that when you call updateLibraryPathInConfig() you can perform an atomical operation and you are sure not to have client read dirty data.
The clients can then update their library as needed. They may even schedule regular updates.
There are a lot of options:
tar + ftp/scp
PEAR (see above #Wayne)
SVN
rsync
NFS
I recommend to use a continuous integration software (Atlassian Bamboo, CruiseControl); check out your repository, build a package, and then use rsync. Automatically.
You should also look into using namespace in order to avoid conflicts with other libraries you might use. pear is probably a good idea for the delivery method, however, you can just place it in the standard path /usr/share/php/, or any other place that is set as the include path in your php settings file.
Good question, and probably one that doesn't have a definite answer. You can basically pick between two different strategies for distributing your code: Either you put commonly used code in one place and let individual applications load from the same shared place, or you use a source-control-system to synchronise between local copies. They aren't mutually exclusive, so you'll often see both patterns in use at the same time.
Using the file system to share code
You can layer the include_path to create varying scopes of inclusion. The most obvious application of this pattern is a globally maintained PEAR repository and a local application. If your it-system consists of multiple applications that share a common set of libraries, you can add a layer in between these (a framework layer). If you structure the include_path such that the local paths come before the global paths, you can use this to make local overrides of files. This is a rather crude way to extend code, since it works per-file, but it can be useful in some cases.
Use source-control
Another strategy is to make a lot of local checkouts of a single shared repository. Some benefits over the layered-include-pattern is that you can make more fine grained local changes. It can be a bit of a challenge to manage the separation between application layers (infrastructure, framework, application). svn:externals can work, but has some limitations. It's also slightly more complicated to propagate global changes to all applications. An automated deployment process can help with that.