On 05/14/2010 10:13 AM, Bob Archer wrote:
>> I am maintaining several different versions of my application and am
>> asking for advice on how to structure/maintain them in the TSVN
>> repository. Do I maintain a full copy of each version in the repository
>> or is it recommended to use "cheap copies"? The remainder of this post
>> illustrates the directory structure I would like to manage with TSVN.
>> Assume there are 3 versions of an application and that about 80% of the
>> code is the same between all versions. The directory structure of the
>> working copy (WC) on the computer might be as follows:
>> About 80% of identically named files between versions will contain the
>> same content (i.e. 20% of identically named files will have slightly
>> different content). For example, the contents in Version1-File1a can be
>> updated separately from Version2-File1a and Version3-File1a. In other
>> words, each version can be updated/maintained separately from the other
>> My question: what is the recommended way to store this directory structure
>> in the TSVN?
>> 1. I could physically replicate the working copy directory structure in
>> the repository. So if version1 WC is 100MB in size, version2 WC is 200MB
>> in size and version3 WC is 300MB then 600MB will be imported/stored in the
>> 2. TSVN supports “cheap copies”. Given that about 80% of the code in
>> version2 and version3 will be identical to version1, it seems to me that
>> another way to maintain 3 different versions is to make use of cheap
>> copies. TSVN uses cheap copies for tags and branches. My reasoning is
>> that cheap copies would reduce the repository size. In other words, if
>> 100MB is imported/stored for version1, 40MB for version2 (i.e. 20% of
>> 200MB) and 60MB for version3 (i.e. 20% of 300MB) then the total
>> information stored/imported is 200MB.
>> My question: can cheap copies be used to maintain 3 different versions of
>> an application (or is this even recommended)? If so then do I simply
> This is how we have our repository set up.....basically...
> Each version is a copy of the previous release... this allows for merging changes made in the previous version to the newer version. If you don't use "cheap copies" as you call them that means you have no ancestory and can't merge.
> So, for example... if our next immenent release is v6.0.0 we would have the folder:
> that we are doing dev in. The next version is v6.1.0. At the point we are ready to start working on it we create a copy (branch if you prefer to call it) of Project1/v6.0.0 to Project1/v6.1.0.
> Once a week we merge any changes to v6.0.0 to v6.1.0. This way we don't have to duplicate that work. At least for us, anything we fix/add to a version always gets rolled up to any newer versions.
> We use our "branches" folder only for feature branches. We use feature branches for larger features that will take a while and be worked on by more than one dev. We keep the branch updated by merging into it from its copy source. Once the feature is done we --reintegrate it back to its source.
>> create a tag or branch for version2 and version3 and then commit all new
>> changes to these tags/branches? I know this works but my read of the SVN
>> document is that tags/branches were never intended for this purpose. If
>> true then is there another way to use "cheap copies" to maintain 3
>> different versions?
> Essentially a "copy" is a branch. There really is no difference.... it is basically a path in the repository who's ancestory comes from another path. What you call it or where you put it in your repo folder structure is really up to you.
What Bob said. I tend to divide mine into ProjectName/Dev and ProjectName/Release, with the "trunk" effectively being Dev/Main, and Dev/[DevVersion] as branches, and Release/[Version] as the tags.
It's all a matter of what makes sense to you.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-05-14 21:15:40 CEST