| ||||||||
Line: 15 to 15 | ||||||||
---|---|---|---|---|---|---|---|---|
RCS cheat sheet | ||||||||
Added: | ||||||||
> > |
Basic process | |||||||
| ||||||||
Added: | ||||||||
> > |
Other commands
More information | |||||||
For more info, see: rcsintro(1) , ci(1) , co(1) , rcs(1) , rcsdiff(1) , ident(1)
Subversion | ||||||||
Changed: | ||||||||
< < |
NOTE: We're not using Subversion presently. | |||||||
> > |
NOTE: We're not using this Subversion idea. We tried something like it, and it went badly. More effort likely could make it workable, but we never bothered. | |||||||
Subversion planning |
| ||||||||
Line: 24 to 24 | ||||||||
---|---|---|---|---|---|---|---|---|
Subversion | ||||||||
Added: | ||||||||
> > |
NOTE: We're not using Subversion presently. | |||||||
Subversion planningWe initially decided to go with Subversion, as it's similar to the CVS/RCS tools many are familar with, we had some expertise in the group, and Subversion is a well-known project. |
| ||||||||
Line: 6 to 6 | ||||||||
---|---|---|---|---|---|---|---|---|
Until such time as our grand unified revision control system using Subversion is working, we're making due with that old stand-by, RCS. Selected config files are under RCS. You can generally recognize such files by the following: | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
|
| ||||||||
Added: | ||||||||
> > |
RCSUntil such time as our grand unified revision control system using Subversion is working, we're making due with that old stand-by, RCS. Selected config files are under RCS. You can generally recognize such files by the following:
sysadm , and can thus be checked out using a regular user account. Some files have to (or really should be) owned by root. Those need you to run the RCS commands as root using sudo . That looses the benefit of RCS tracking who did what, but at least it still tracks what was changed when. And you can always put your name in the checkin comments.
RCS cheat sheet
rcsintro(1) , ci(1) , co(1) , rcs(1) , rcsdiff(1) , ident(1)
Subversion | |||||||
Subversion planningWe initially decided to go with Subversion, as it's similar to the CVS/RCS tools many are familar with, we had some expertise in the group, and Subversion is a well-known project. |
| ||||||||
Changed: | ||||||||
< < |
We learned a lot about revision control. But probably the biggest is that no Open Source package is really suitable for doing revision control for every/most files on a live system. But I'm getting ahead of myself. | |||||||
> > |
Ideally, it would be nice to have everything on a system under some kind of formal revision control. This would let everyone see who changed what, when they did it, and nominally, why. | |||||||
Changed: | ||||||||
< < |
We had somewhat decided to go with svn. The reasons are ... | |||||||
> > |
Subversion planning | |||||||
Changed: | ||||||||
< < |
After some discussion and prototyping things, a message was posted by our SVN guru (Paul Lussier) describing what he learned. | |||||||
> > |
We initially decided to go with Subversion, as it's similar to the CVS/RCS tools many are familar with, we had some expertise in the group, and Subversion is a well-known project. | |||||||
Changed: | ||||||||
< < |
You may also be interested in the discussions preceding this. See the following threads: | |||||||
> > |
After some discussion and prototyping, a message was posted by our SVN guru (Paul Lussier) describing what he learned. There was some further discussion here, here, and here. | |||||||
Changed: | ||||||||
< < |
||||||||
> > |
We decided to go ahead and put (almost) all of /etc/ and /usr/local/adm/ under revision control. Announcement. There was some follow-on discussion about the performance of asvn and maintaining permissions. | |||||||
Changed: | ||||||||
< < |
Comments? | |||||||
> > |
That initial experient went awry, apparently due to bugs in the "asvn" script we were using at the time. See this list discussion. As of this writing, we don't have a real solution in place for revision control. There are some scattered RCS directories around, but I'm not sure everyone is using them. -- BenScott - 03 Apr 2006
Subversion implementation(Editor's Note: Most of this is NOT in effect as of 3 Apr 2006.) At this moment in time, we will be keeping all/most configuration files under revision control using svn (subversion). This is similar to CVS/RCS/SCCS and other file version control tools, but works much better with directories of files. The following was issued by Paul Lussier (our svn expert). Please update it as situations warrant. Here's the layout of the repository so far:gnhlug/ branches/ production/liberty/ usr.local.adm/ AdminContacts ChangeLog gnhlug-10-Feb-2006.tgz CentOS-4.2/ changes/ pkgs/ user-keys/ tags/branches and tags are currently unused. I doubt we'll ever need to use tags, but I can see us using branches for "playing" with things outside of the "production" tree. For example, suppose you want to play with a firewall config file, and you want to check out the repo to your home system and test the config out there. Create a private branch under gnhlug/branches/ mkdir ~/sandbox cd ~/sandbox svn co file:///usr/local/svn/gnhlug gnhlugYou should end up with the above described hierarchy in your sandbox dir. If you want to check the repo out to your home system, first do this: On the system you wish to check the repo out to, edit ~/.subversion/config (this will get created the first time you run svn...). Uncomment the line containing '[tunnels]' and create a blank line below that as well. Then add the following line: gnhlug = ssh -p 1776 You should have something similar to: [tunnels] gnhlug = ssh -p 1776 save'n'quit. Then, as on liberty, find a location to check out the repo to: mkdir ~/sandbox cd ~/sandbox svn co svn+gnhlug://liberty.gnhlug.org/usr/local/svn/gnhlug gnhlugYou should get the repo checked out into ~/sandbox/gnhlug Because of the rpm's in this repo, it was taking a really long time to check this repo out. I got fed up with waiting to check it out, and ended up deleting the files from repos (not from the actual file system though). There's no need to have rpms and tgz's in our repo when we can always get them elsewhere on the net. If we have rpms that we've built, then we want the source trees under rev control, not the binaries themselves. I've also set an ignore property on the repo to ignore files of type '*.[tgz,tar.gz,bak,~,rpm]'. This will allow us to keep these files in the working copy of the checked out repo on disk, but have subversion ignore them so they don't get accidently checked in and clutter things up. Play around with this repo if you want, get familiar with svn, do whatever. If you have questions, let me know, I'm glad to help. | |||||||
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Added: | ||||||||
> > |
|