How do I generate a default comment for cvs? I'd like every checkin comment to start with "Change #: " and be available for the user to edit.
I know this can be done globally in the repository. Can it also be done as a single user on the client side?
I am using command line cvs.
We already have verification that the checkin starts with "Change #: " and that a valid change number is provided. I'd like to default the checkin comment to "Change #: " to save developers some typing. How can this be done globally? Can it be done locally/client side?
Be cautious. You must also ensure that the default comment does not become a crutch. For example, you should validate that the defect number is valid (currently open, for example, as well as actually exists). Otherwise, the programmers will simply use the default comment as the only comment.
In my view, it would be better to put the effort into validating the comment than into providing a default. Tell the developers that their changes will be rejected unless the comments meet the requirements - and document what is expected (and accepted).
The questioner challenges "nicely said, but does not answer the question".
Fair enough. I don't really use CVS, so take what follows with a pinch of salt.
Looking at Karl Fogel's book "Open Source Development with CVS" (Coriolis, 1999), I don't see a good way to do it. There are 'commitinfo', 'loginfo' and 'verifymsg' files that all seem to specify programs that validate log messages, and the editor is launched when the user doesn't specify 'cvs ci -m"Why I committed this"' (or, 'cvs ci -F why' for a message in a file), but personally I always checkin with comments on the command line and would hate to have an editor launched for me. So, short of writing a wrapper for the cvs command (which would be moderately complex), I don't see a way in the book of doing what you request.
Hmmm...unless you override the user's definition of CVSEDITOR in a shell script wrapper for cvs with a program that creates the default message in the given file and then launches ${VISUAL:-${EDITOR:-vim}} instead. Ick, and likewise yuck! But, done carefully, it would work. Probably the hardest part is ensuring that the programmers use your script version of cvs instead of the binary.
You can use the rcsinfo file to specify a template to use for the check in.
See this page for details.
This is done server side, so you need your template files on your server.
Also, as noted above, you can override the template with your own check in comments on the CVS command line.
Related
Please bear with me here, because I'm a beginner when it comes to version control systems. I've decided to start with the very simple GitHub app. What I want to do is (because I work in Dreamweaver) when I save a file a window to pop-up and ask me if I want to commit, is something like this achievable and if so... then how?
Perhaps there's a solution that uses a directory watcher to watch for changes and then prompt?
In my opinion, this isn't really a good solution though - you don't just want to use Git as a "backup" solution, you want each commit to be a mini-milestone that represents some logical group of changes. I can't think of a single instance where the first time I saved a change to a file it was commit-worthy. If you were to commit with every save, how would you ever test those changes?
I haven't used it myself but the GitWeaver extension may be what you are looking for.
I've run into the problem described in this question, where an old package was Obsoleted, and its %preun script is run with $1 = 0, resulting in undesirable behavior. I know this could be worked around by using -e + -i, as suggested in that answer, or the --nopreun flag, but it's difficult to get that information out to users who are accustomed to simply using -U.
I can't modify the existing %preun scripts in the wild. I don't see any way to run additional code from the new package after the old one's preun. I can't find any way to have my new package programmatically prevent the old %preun script from executing.
Is there any safe way to reach into the RPM database and remove a scriptlet for an existing package?
Jeff Johnson is absolutely correct that it should not be done. However it certainly can be done.
I have done this in an RPM at work, for distribution, but note, this was a contained semi-structured environment with no remote hands to all systems.
If you have remote hands access, take the "remove, install" path, and script that.
If you really feel you should be doing this, then these are the pointers. I'm not going to show you exactly how I did it because it was "work" and not mine to share. The concepts are mine :-)
First, back up the /var/lib/rpm/Packages file (cp /var/lib/rpm/Packages /var/tmp/Packages.bkp). Put it somehwere safe. Update your backup if any one else changes the system whilst you are working on your solution. MAke regular checks on the count of RPMs and test every which way from Sunday, after each change or step.
You will need to use the db_unload and db_load commands. For speed, you will need to use "s2p" to convert any shell sed patterns to perl. Then build a pipe which looks like this:
db_unload /var/tmp/Packages.bkp |perl -i -e "s2p converted string" |db_load /var/tmp/Packages.new
You can then attempt to test the Packages.new by copying ot over the original. Always run rpm --rebuilddb after manual changes. If you see any errors, restore the back up and rebuild the db again.
If you need to put it in an RPM, then convert it to Lua, and put it in the pretrans or posttrans scriptlet (%pretrans -p <lua>). The selection depends on the ordering you are trying to achieve. The Lua interpreter is built in to rpm, and so it will run OK during a new system install even if your RPM gets called somehow. I wrapped my "pipe" in a lua long string, and made it only execute if the system already exists. It does nothing otherwise. If you are thinking "that will never happen" then check out "Never say Never".
BTW you can completely stiff your RPM base and thus future administration of the system if you mess this up. If you do that, and have no backup or way out, it would be a hard way to learn that you are responsible for your own actions. Just saying that you have been warned!
No you cannot edit an rpmdb: the headers are protected
from change by a SHA1 or a digital signature.
Instead upgrade to a fixed version of the package using --nopreun
to prevent running the buggy script let.
I working on a company machine and cannot change the name of the windows username. I am running TortoiseSvn locally and I would like to change the commits to my name. I do not want to right click each commit and manually change the names. Is there a way to do this? I know that there are a couple of threads about this but there are no solutions.
Yes, there is a way to do it, but you probably can't.
In Subversion, there are two types of properties: File properties that are revisioned with the file itself, and Revision properties that are attached not to a file, but to a revision. These are not versioned.
There are several standard revision properties:
svn:log: This is the commit comment.
svn:author: This is the user who made the commit.
svn:date: This is the date and time stamp of the commit.
You can change any of these revision properties with this command:
$ svn pset svn:log --rev-prop -r193 "The commit comment for revsion #193 is this!"
It would be fairly simple to write a script in PowerShell or Python or Perl to do this to a whole bunch of revisions at once. However, you can imagine what type of havoc this could wreck if you could change the date, authorship, and commit comment of any Subversion revision at whim.
Therefore, in order to be able to use a rev-prop change, the repository must have a hook to allow you to do this. This is the only case where you must have a hook to explicitly allow a permitted action. And, of course, it is highly doubtful that you will have the ability to create such a hook.
Now, I'm assuming you were talking about already committed revisions. If you are sharing a working copy, and you make changes, and then commit those changes along with everyone else, you're using Subversion all wrong.
Each user should have their own working directory where they can make changes. This way, the repository will record who did the commit without any shenanigans.
If you simply want to checkout from the repository with a name other than your Windows name, you can save your authentication on your local machine, and Subversion will use that authorization when it does checkouts from that repository.
I believe that authorizations are stored under the %HOMEPATH%.subversion\auth directory. It shouldn't take too long to find the file with the authorization and delete it. Then, when you checkout the next time, you need to specify the user and password and save the credentials. After that, that's what TortoiseSVN will use by default when you use that repository.
That's three different answers covering three different situations in using Subversion and credentials. If I didn't answer the correct scenario, edit your question and explain exactly what you mean and what you want to accomplish. The situation you describe isn't very clear.
Here's the scenario I'm currently running into:
Programmer A (Using a Mac Version of Dreamweaver) edits file client.php and commits that file to the production branch of Project Foo's repository
Programmer B (Using a Windows Version of Dreamweaver) edits file client.php to fix a bug in the that file. He then does a cp clientInfo.php ../prod-branch/clientInfo.php to take that bug-fix from his working copy to the production branch.
Programmer B then does an svn diff ../prod-branch/clientInfo.php to see what svn says his changes were only to discover that svn says he's changed every line in the file!
Now, this is what I believe is happening:
When the file gets edited by Mac, Dreamweaver on Mac replaces all the Windows newline characters with Mac newline characters so that it's readable in Dreamweaver. In short, Dreamweaver has altered every line in the file. Now, once the commit is done, svn sees that every line of the file has changed and marks this fact down. When the windows programmer makes a change and the newline characters get changed again, svn thinks that, again, every line has changed.
My question is this: How can we prevent this from happening? I know there's no way to undo the damage that's already been done, but I want to prevent this from happening in the future.
You need to use the "svn:eol-style" property on all text files. Usually setting it to "native" will suffice
Dreamweaver has an option to set which line break type it uses. Edit (on Mac: Dreamweaver ) -> Preferences, Code Format, Line break type.
Get your users to have the same setting, and things should play a little better together. It would be better, of course, if you can set your source control to ignore line break differences.
svn:eol-style is a property that can be set centrally in the repository and should sort out your problem.
Check out the chapter on New Line Sequences in the Subversion book.
The solution to this problem is the svn:eol-style property. When this property is set to a valid value, Subversion uses it to determine what special processing to perform on the file so that the file's line ending style isn't flip-flopping with every commit that comes from a different operating system. The valid values are:
I have a class, which is part of a code library project that was written for a particular purpose that is no longer required. So the question is what do you do with code like this? Do you simply delete it, or do you leave it in bearing in mind that future developers may come across it and not realise that they can disregard it or do you have some sort of archive system, is there a recognised "pattern" that is in use...
Delete it. You can always get it back from the version control system later. You do have version control, don't you?
As Neil said, delete it. If I'm hired to maintain your project years after you are done with it and it's still full of dead code.. I'm gonna haunt you. And not the ooooohhhhh nice kinda haunting.. but the ARRRRWWWGGGGGRRRR!!!!! annoying kind of haunting.
It depends.
If it is unused because it is obsolete, I would clean it from the current code base by deleting it. If it turns out that it is in fact needed, you can always retrieve it from source control.
If it is unused at the moment, but may be used in the near future, I would keep it in the current code base as I wouldn't expect fellow developers to browse the source control for features just in case. In other words: if you delete something that has a high chance of being used, chances are that someone will re-implement it.
If it is not used anywhere, and no longer required you should delete it to avoid confusion.
You didn't say what code you are using but in C#/VisualStudio you can use the Obsolete attribute to tell other developers not to use the code, you can set the errors argument to true, and this will break the build anywhere that the code is being used.
I would start off by tagging the out-dated code elements with the Obsolete attribute. That way you will be able to locate any code that refers to the out-dated elements, giving you a way to update those parts. When you no longer get any compiler warnings that you use obsoleted code, go ahead and delete it.
Update: OK, now I was thinking .NET and C#, but I am sure many other languages have similar features...
I try to keep my application code as little as possible. Library code should be compatible for a number of release then remove it or just mark it as deprecated.
I totally agree with Neil. Use SVN or any other version control system to keep track of your code and delete anything that is redundant. Too much commented code only makes your code hard to read, and in some cases debugging impossible.
The best option is to remove the code so you have a cleaner repository. Most of the time it is just a short term fealing you delete somehting of potential enormous value.
Counting on svn if fellow programmer need it later won't really work. Because you have to know the code existed before and then some has to scan through the svn.
If I really think I want to keep that code than I usually make an archive out of the files and add them with a description into our wiki and then I delete the code. Over the search of the wiki someone can find the code. Scan it using the archive and as the decription contains repository and revision number they can even ressurect the parts they need easily.
If it's much, reusable and/or code difficult to reproduce, I usually put it into a file called <projectname>_rubbish.<ext>. Not very elegant but I can easily ignore it and also look for it seamlessly when I do need it again.
Install GIT then:
cd <code repo>
git init .
git add .
git commit -m 'inital import for my old code'
... Refactor the code ...
git add <path/to/file/with/changes/>
git commit -m 'that feels much better... :)'
... Create an account on GitHub or setup a GitServer
git remote add origin <remote git repo>
git push origin master
And you're done... :)
Simply delete it. If it is no longer required, there is no point in keeping it.