Subversion vs. CVS - Sticky Tags

[Aho Thomas Rolf <cz...@ocag.ch>]

Hi all,

We are thinking of switching from CVS to Subversion, but there is one
thing I
am not quite sure how to do in Subversion.


Consider a workspace with three files; "common1", "common2" and
"special".
We have different customer-versions (not revisions, rather versions in
the meaning
of flavours) of the SW, and we have organized the code so that "common1"
and "common2" 
contain code that is independent of the customer. All code that is
customer
specific goes into the file "special".

With CVS I commit "common1" and "common2" on the main branch. 
I will commit "special" on a separate branch for each customer. 

Now say that I have 2 customers and the branches "cust1" and "cust2". To
set up a 
working view for customer 1, in CVS I would do
    cvs checkout .
    update -r cust1 special

Whenever I want to update my view with the latest changes on "common1"
and
"common2" I make a
    cvs update
This updates my workspace with all the committed changes on "common1"
and "common2"
on the main branch. 


I do not see how I can do this in Subversion. It seems to me that I am
forced to branch
all files, and do a merge in order to get the newer versions of
"common1" and "common2".
The drawback with this is that I need to keep in mind that "special" is
the only file
I do not want to perform a merge upon. In CVS the tool remembers this
automatically for
me, by having a sticky tag set on it.


Am I missing something?


Thanx in advantage for any help!


----------

Thomas Aho

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Subversion vs. CVS - Sticky Tags

[Ryan Schmidt <su...@ryandesign.com>]

On Jul 5, 2006, at 16:28, Aho Thomas Rolf wrote:

> Consider a workspace with three files; "common1", "common2" and
> "special".
> We have different customer-versions (not revisions, rather versions in
> the meaning
> of flavours) of the SW, and we have organized the code so that  
> "common1"
> and "common2"
> contain code that is independent of the customer. All code that is
> customer
> specific goes into the file "special".
>
> With CVS I commit "common1" and "common2" on the main branch.
> I will commit "special" on a separate branch for each customer.
>
> Now say that I have 2 customers and the branches "cust1" and  
> "cust2". To
> set up a
> working view for customer 1, in CVS I would do
>     cvs checkout .
>     update -r cust1 special
>
> Whenever I want to update my view with the latest changes on "common1"
> and
> "common2" I make a
>     cvs update
> This updates my workspace with all the committed changes on "common1"
> and "common2"
> on the main branch.
>
> I do not see how I can do this in Subversion. [snip]

I believe this should be possible by switching just the special  
directory.

Consider a repository layout like this:

$REPO/
	proj/
		trunk/
			common1/
			common2/
			special <-- is empty or maybe contains a skeleton for new customers
		branches/
			cust1/
				special/ <-- the version for customer 1
			cust2/
				special/ <-- the version for customer 2

To create a new working copy for customer 1:

	svn checkout $REPO/proj/trunk .
	svn switch $REPO/proj/branches/cust1/special special

To update it with the latest changes:

	svn update



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Subversion vs. CVS - Sticky Tags

[Andreas Pakulat <ap...@gmx.de>]

On 05.07.06 16:28:17, Aho Thomas Rolf wrote:
> I do not see how I can do this in Subversion. It seems to me that I am
> forced to branch
> all files, and do a merge in order to get the newer versions of
> "common1" and "common2".
> The drawback with this is that I need to keep in mind that "special" is
> the only file

What you're looking for is svn:externals, however I'm not sure wether it
works on simple files. It allows definetly works on directories, i.e.
you have

workspace
  |
  - common
  |
  - some source file

and in common is everything that is common to a couple of your projects.
Now when you do an initial checkout of project1 you automatically get
common and in it the latest from the url that it points to.

Also any svn update on the workspace updates common. Checkins need to be
done explicitly from inside common, so commits you do on the workspace
only commit the files that are outside common.

Andreas

-- 
You have an ambitious nature and may make a name for yourself.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org