I have a project, hosted on launchpad, which contains a fairly user-specific configuration file.
Once the project is initially checked out, obviously this .cfg file should also be downloaded. However, further updates (via "bzr update") would ideally not alter this .cfg file, as the user would have made their own edits to it. These edits would be overridden / merged should (with potential conflicts) I push an update using the code with my own .cfg file - I don't want this to happen!
What's the best practice to avoid this? I can't really "bzr ignore", as then any future users checking out via bzr would then not have the .cfg file.
I could, of course, replace my .cfg file with the "stock" one each time I do a commit, but this seems a bit clunky.
Or equivalently clunky, supply the .cfg file separately.
What I'm looking for is a "single-shot" download, but never update subsequently.
Any advice?
This is a tricky problem, because version control systems in general are not engineered to have the fine-grained commit strategies needed for this approach. If you were operating in a controlled environment, you could use plugins or hooks to exclude certain files from commits etc., but that doesn't seem to be an option here. I'll add that bzr ignore won't help you, either, because it only prevents files from being added; it doesn't prevent commits or checkout of those files.
What you can do is generate the config file during build/setup/installation if it doesn't already exist. Something like:
#!/bin/sh
if [ ! -e configuration.cfg ]; then
cp etc/configuration.cfg.in configuration.cfg
fi
Here, you'd check in etc/configuration.cfg.in normally and run the above script at build/setup/installation (this could also be automated by a post_change_branch_tip hook in a controlled environment). You'd put the original in a different directory so that there's less of a risk of it getting edited by accident.
Related
I am looking for best practices using branches in RCS.
I had read the man page for rcs and ci and also browsed at the following links:
http://www.gnu.org/software/rcs/manual/html_node/Concepts.html
http://www.gnu.org/software/rcs/manual/html_node/Quick-tour.html
Suppose i have revision 1.3 on tip of the trunk.
I now want to change file 1.2 (as 1.3 have several other changes I cannot yet use).
I understand I can create branch on revision 1.2 using ci -r1.2.1
My question are the follows:
1. Do I need to set a lock on the file? If so, on which revision?
2. If no lock set, I cannot use -u flag in order to keep the file in my local dir. In case I wish to do so, is it still possible without co the file again?
Side note: I feel RCS does not suit my company needs however migrating to another system is not my decision to make, so currently I need to keep working with it.
I'm looking for much the same thing, but seeing you've had no answers, I'll offer my current practice:
I use branches for development, not for keeping different variants going in parallel. The trunk is reserved for my best, presumably working, code on the and I try not to check in anything there that might break it. I branch the code when I want to start a line of development that will take some time, break it for a while, is an experiment I might have to be abandon, etc.
To start a new line of development I change the default branch to a new branch off the trunk rev that's to be the base of my code, and force a checkin onto that branch, with:
rcs -b1.2.1 foo.cpp
ci -f1.2.1 -l foo.cpp
Now I can dive in to developing the branch, and my next check-ins will go onto the new branch instead of onto the trunk. Whether you lock a revision or not is only relevant to whether you intend to modify the working file.
You're correct that you can't keep both revisions, trunk-tip and branch-tip in the same folder; they have the same file name. But you can check out one of them with a -p switch which forces the output to stdout (instead of to a local file) which you can then redirect into a sub-folder, or to a local file with a unique name.
Using Struts 2: when will the .tmp file - that gets created after uploading a file - be deleted?
How can you customize when the .tmp file should be deleted? Do you have to create a copy of it?
Please don't be shy to give some code :)
1. This depends on which version of S2 you're talking about.
S2.2.1 and prior: the file upload interceptor deleted temp files.
S2.2.3 and above: the filter dispatchers start the deletion process, changed due to WW-3490.
2. Assuming you're using a recent version, it might be possible to inject a tweaked Dispatcher, although it's not immediately obvious how–if it is, that's the easiest change at the core level.
The easiest approach from a practical standpoint is to copy files in the action, which is also pretty fast on any reasonable file system.
This question already has answers here:
What is the best practice for dealing with passwords in git repositories?
(9 answers)
Closed 8 years ago.
Along the code there could be very sensitive information such as passwords, amazon s3 keys, etc that I don't want to be sent to git at all.
I'd like those very specific fields to either be replaced with "SECRET" or something like that.
Also, is git private repo solving this?
Since git tracks text and not just files, replacing these lines with some other text would be interpreted by git as a change on the code, so it would overwrite the original sensitive info in the next commit.
What I use to do in these cases is to modularize my code so this info get isolated in a single file, and then I add a line with the file name to the .gitignore file.
The .gitignore file is a collection of patterns, one per line, of file names to be ignored by git while tracking changes in your repo.
For example, if I'm writing a web system in php, I create a file that only store info about credentials for connecting to the database (frameworks use to do so too, so you could guess it's a good practice...). So I write this file once with the test server credentials (which my collaborators are supposed to know) or with some dummy credentials, commit it and push it to my remote, and then I add the file name to my .gitignore.
In the other hand, you have the command git add -p, which interactively let you skip lines, but that would result on a file without the mentioned lines in your remote repo, an you having to manually skip the lines every time you add the file...
A Good reference for git is Progit. Highly recommended if you are starting with git... Also, Github's help center is a very good place to look.
I hope it would be helpful! good luck!!!
I have a drupal site, and I am storing the codebase in a git repository. This seems to be working out well, but I'm also making changes to the database. I'm considering doing periodic dumps of the database and committing to git. I had a few questions about this.
If I overwrite the file, will git think it is a brand new file or will it recognize that it is an altered version of the same file.
Will this potentialy make my repo huge (the database is 16mb)
Can I zip this file? or will this mess Git up ... the zipped version is only 3mb
Any other suggestions?
If you have enough space, a non-compressed dump in source control is pretty handy because you can compare using a diff program what rows were added/modified/deleted.
Another solution is to use the features module which is supposed to capture drupal config in code. It stores this captured data as a feature module which you can put into version control.
For my database applications, I store scripts of DDL statements (like CREATE TABLE) in some sort of version control system. These scripts sometimes include static "seed" data as well. All the version control systems I use are good at recognizing differences in these files, and they are much smaller than the full database with data.
For the dynamically-generated data, I store backups (e.g. from mysqldump) in an appropriate location (depending on the importance of the data, that may include offsite backups).
1) It's all text, so GIT will just see it as it would any other file.
2) No, due to the above it should add 16mb to the repo (or less, due to GITs own compression), it won't add a new file every time, just the changes, so the repo will change by the size of the additions to the repository
3) No, or GIT won't be able to see the differences - GIT does it's own compression anyway
A colleague has imported a CVS repository into a pre-existing SVN repository using a cvs2svn dumpfile (like "svnadmin load --parent-dir /path < dumpfile") , which I originally created from the CVS repo.
Now that I'm trying to checkout and build from SVN, I've noticed that some files seem to be missing in the SVN checkout that were present when I checked out the same branch from CVS, although the majority are present. They are mostly but not exclusively binary files (jars and gifs etc.) and I think (though I haven't checked exhaustively) that they are also files that have not been modified on the branch that I'm trying to check out. I should also point out that they don't show up using cvsweb (I would provide a link to the cvsweb documentation but I have no way of knowing its version etc), although they do appear doing a standard checkout of the branch.
If anyone has any idea what's wrong here, or where to start looking to address this, I'd be very grateful! New to SVN so not sure if this is normal! Also, I know I could fairly easily "fix" it by copying over the files but I'd ideally like to keep their revision history so a more complete solution would be preferable. Thanks!
That sounds that the configuration which has been used during the conversion has been wrong. May be a property in svn exists which represent the CVS revision information. If not you're lost..more or less...A good suggestion is to test such migrations and check the contents of the resulting SVN repository...and of course do make backups ...BTW. Are these branches are removed in CVS before?
This is not normal; such files should be handled just fine by cvs2svn. Your best bet is to create a reproducible test case (instructions for doing so are in the cvs2svn FAQ) and report the problem to the cvs2svn users' mailing list.