[GLLUG] More Subversion

frank.dolinar at comcast.net frank.dolinar at comcast.net
Mon Feb 4 13:45:02 EST 2008


Richard,
    I've looked on Amazon and have found a number of books that have the phrase "Pragmatic Programmer" attached, but none that identify themselves as having anything explicitly to do with version control in general or Subversion in particular.  Would you please provide me with an exact title, the author(s), and the ISBN of the book you have in mind so I can find it?
    Regarding backing off of the project.  Sounds like a wonderful idea and very restful.  However, I have to explain this to my co-workers this week.  Wednesday would be nice.  Delaying a week or more from now just isn't an option.
    The reason I've asked these questions is to get enough understanding so we can do what we need to do to get this project off the starting line and use Subversion in the process.

    To all: feedback in answer to any of my questions is still of interest.  Don't be shy.

Thanks in advance.

Frank

-------------- Original message -------------- 
From: Richard Houser <rick at divinesymphony.net> 

> -----BEGIN PGP SIGNED MESSAGE----- 
> Hash: SHA1 
> 
> Frank Dolinar wrote: 
> | Hi, everyone, 
> | Thanks for all the feedback. I really do appreciate it. Now I need 
> | some more. 
> | 
> | I have the SVN manual suggested by Charles and have been reading it. 
> | I have an operational repository at work. I've put in a couple of 
> | files, verified that they are there, and retrieved them. 
> | 
> | However, I still need a bit of help (possibly a lot of help) to get 
> | a functional understanding for a real development effort. I need to 
> | know what the process looks like for a set of files, and -- more 
> | specifically -- what the process looks like when there are multiple 
> | developers working on the same project, or, worse, the same file. 
> 
> The process is described in detail in the reference I mentioned. More 
> than anything, it sounds like you are trying to move ahead with the 
> implementation without really understanding what the goals of the 
> revision control project really should be. I strongly suggest you back 
> off on the implementation until you have a reasonable expectation of 
> what you want to get out of this. 
> 
> | If you can provide a couple of step-by-step examples of how 
> | subversion is used on a daily basis, that would be particularly 
> | helpful. [Yes, I'm reading that part of the manual, but it's the 
> | biggest part of the manual and a shorter summary would help for my 
> | immediate needs.] When I'm trying to learn something, I have to read to 
> | get the concepts, listen to what other people tell me they have done, 
> | and then spend time actually doing. 
> 
> The Pragmatic Programmer Version Control book I mentioned will take you 
> through the concepts, and provides example syntax. You can follow along 
> in the book playing with a sample repository. 
> 
> | I have the following understanding at this point. Please feel free 
> | to correct me if my understanding is inaccurate. 
> | 1) I assume that each separate project, when created, is kept in a 
> | different folder in the repository, and, when created, begins its own 
> | trunk of code (set of files for the project) which are subsequently 
> | modified and after the first time any given file is placed in the 
> | repository, only changes to that file are retained by subversion. 
> 
> Subversion tracks modifications to the repository, not just individual 
> files. The lack of tracking on directories/repositories was one of the 
> biggest complaints about CVS. 
> 
> You should pick one of two models: 
> 
> 1.) each project has it's own set of trunk, branch, tag directories 
> or 
> 2.) each project exists in it's own directory immediately inside of the 
> trunk/branch/tag directories and the version labels apply to all 
> projects as a while (ex. related projects that might be revisioned together. 
> 
> The choice is up to you, but don't deviate from these patterns until 
> you've been doing revision control for a couple years. Until then, you 
> won't have an idea of the problems you would otherwise run into. 
> 
> | 2) Branches are the modifications to the initial trunk of code that 
> | have been saved as "stable, working" versions, that are identified / 
> | labeled as "milestones" for want of a better word, and which can be 
> | referenced as needed to retrieve specific versions of the project (trunk). 
> 
> Not quite. Very often branches are NOT stable, and are forked off to 
> develop a new feature that would otherwise break other development 
> efforts. Branches are primarily useful to isolate development changes, 
> such as from a previous official release (a dead-end) and recent 
> development efforts (trunk). 
> 
> | 3) Tags are used to identify (i.e. label) these branches at the point 
> | that the code is evaluated as being stable and working. 
> | 
> | Someone indicated that even after a tag has been applied to a branch 
> | of code the branch can continue to be changed. This confuses me. I 
> | would have expected that once a tag has been associated with a branch of 
> | code, that it's really a milestone along the trunk that can be used to 
> | revert to a previous version of the project's code and therefore would 
> | NOT be changed as part of that tag. Please advise. 
> 
> Tags and branches are technically the same underlying feature. The 
> difference is how they are used. If you use a tag as a branch, it's 
> going to act like one. Once again, this is explained in that book (it 
> really is a short read). 
> 
> | Can anyone give me some sense of how fast the content grows? I have 
> | an application written in Visual FoxPro that's about 7Mb. A couple of 
> | others written in VB.Net that will be about 4Mb an 10Mb of source code 
> | respectively. What kinds of growth rates are you seeing? The 
> | repository is currently limited to 4Gb of space. Am I likely to run out 
> | of space in the foreseeable future? 
> 
> This really depends on your particular data. Subversion will try to 
> primarily store diffs, however, so it does minimize the wasted space. 
> If you have 4Mb (512KB) of source code, and 512MB of available space 
> (4Gb), you would have enough space for 1024 complete copies of the 
> repository. Absolute worst case scenario, if your existing data set was 
> all binary data, you would get approximately 1000 updates per file 
> before the space was used. With typical source and your small developer 
> numbers, you will likely be fine for years at that rate. Check your 
> growth rate in a month to get a better estimate. 
> 
> | Again, any help will be much appreciated. 
> | Thanks in advance. 
> | 
> | Frank 
> | 
> | 
> | ------------------------------------------------------------------------ 
> | 
> | _______________________________________________ 
> | linux-user mailing list 
> | linux-user at egr.msu.edu 
> | http://mailman.egr.msu.edu/mailman/listinfo/linux-user 
> 
> -----BEGIN PGP SIGNATURE----- 
> Version: GnuPG v1.4.7 (GNU/Linux) 
> Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org 
> 
> iD8DBQFHppocUMkt1ZRwL1MRAuvbAJ9Jgu5GwWLwb6XkRglf74v0V+VaKwCeMfAs 
> 56j7/mixAwHje4LnwRS7t/8= 
> =cj8S 
> -----END PGP SIGNATURE----- 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.egr.msu.edu/mailman/public/linux-user/attachments/20080204/d56e57bd/attachment-0001.html


More information about the linux-user mailing list