Re: Patching/Updating Perl scripts

You say that subversion/cvs seems bit too much. But then you go on to enumerate a wishlist that sounds almost exactly like the list of features of a good version control system.

My advice is to install either CVS or subversion, and build on top of that. If you'd rather keep control of the project, you need not give CVS wite priviliges to other people - you can keep it to yourself, or give it to people who have earned your trust through consistent quality contributions.

Come to think of it, you're going to need some sort of version control system for your own use anyway, so making it available to others is just spreading goodness.

Comment on Re: Patching/Updating Perl scripts

Replies are listed 'Best First'.
Re^2: Patching/Updating Perl scripts by Ace128 (Hermit) on Dec 01, 2005 at 09:34 UTC
Hmm.. this could be true... Maybe Im too much of a controlfreak ;) It just felt like those subversion/cvs things are not that controllable when it comes to the data changed. I mean, sure I can commit several times, and such... But, as far as I know, I cant really edit the history easly... Crap. Subversion has revision numbers on the whole project! I would prefer per script. Hmm... Also, I wanted to avoid revision 6-8 are "fixes" for like typos. That is, only "final" versions exists in the repository... Hmm... Guess I have to do it myself then... So I get what I want...	[reply]
Re^3: Patching/Updating Perl scripts by tirwhan (Abbot) on Dec 01, 2005 at 10:02 UTC
Maybe you should look into svk which is a distributed version control system written in Perl and built on top of subversion, that should satisfy your requirements for scriptability/control. You could maintain several trees for the different purposes (fixes, updates etc.) and merge as you see appropriate. Also, with svk users can have their own repository with local plugins and you'll just have to devise a clever way for them to merge your central changes with their local tree in a non-confusing manner. Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan	[reply]
Re^4: Patching/Updating Perl scripts by Ace128 (Hermit) on Dec 01, 2005 at 12:37 UTC
Hmm, this is all good. Problem is that it may be too complicated, unless I include svk in my "system" aswell using par (pp) or something... Btw, installing the windows version and running svk I get: Can't locate object method "bootstrap" via package "SVN::_Core" at C:/Program/svk/lib/SVN/Core.pm line 5 BEGIN failed--compilation aborted at C:/Program/svk/lib/SVN/Core.pm line 5. Compilation failed in require at C:/Program/svk/site/lib/SVK.pm line 8. BEGIN failed--compilation aborted at C:/Program/svk/site/lib/SVK.pm line 8. Compilation failed in require at C:\Program\svk\bin\svk line 3. BEGIN failed--compilation aborted at C:\Program\svk\bin\svk line 3.	[reply]
Re^3: Patching/Updating Perl scripts by tphyahoo (Vicar) on Dec 01, 2005 at 12:37 UTC
If you were really a control freak you wouldn't want to edit the history. I'm a control freak, ok? I love subversion! Give it a try. And try subversion before cvs, since svn has got a lot that cvs doesn't. (Main advantage of cvs is it's used more universally, eg sourceforge, but subversion is rapidly gaining in popularity.)	[reply]
Re^4: Patching/Updating Perl scripts by Ace128 (Hermit) on Dec 01, 2005 at 18:38 UTC
I've actually installed Tortoise here in windows, and find it really nice. However, one of the big problems with these bigger systems is that they are too hard for average Joe. Reprository? Checkout? What is all that about, may they say. Hmm, and I really dont think I need that too advanced applications... Since, I can only imagine I need to update scripts with new subs... (and maybe some new global variable)... and since Perl is so good with text and files handling I think I will try to create something on my own. Nothing too advanced I think though, but still. Heck, I was even thinking that each plugin could have a list of subs that expanded that particular plugin, and users may "add" these as they want :) Sounds quite cool to me actually ;)	[reply]