You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by James ORourke <jo...@collab.net> on 2008/03/05 19:41:05 UTC

Is there a better way than using sym links....

Hi All,

Potential migration from PVCS to SVN.  There are 3 main projects.  As with most development organizations code such as libraries and headers are shared.  Today they live in each of the projects with sym links.  Goal is to have the ability to update/modify these shared files and have the changes updated in the other projects and be able to update them from any project.  Sym links in PVCS is not fool-proof and has its own limitations.  Part of that could be how we implemented the process.  

If migrated to SVN, the thought was to create a separate project just for the shared code and then use sym links to the other projects that need the code.  This at least forces on central place to make the changes, where today its not the case.  Would sym links still be needed here?  Or is this where "externals" come in to play (if I understand externals correctly)?  There may be times when these other projects will not want the latest version of these shared files.  For legacy customers, the need may be to use an older version, or a custom version (i.e. branched version).  Could this still be accomplished as described above, or is there a better approach?  Assumptions would be that branching and merging happens in the project that has the shared code.  If I have externals, I would update the definition/configuration to make sure the right versions are pulled into the project(s), correct?  

To further explain the dilemma:

There are mainly 3 different products.  For simplicity I'll refer to them as Small, Medium and Large.  As stated above, although the products are different there are certain things that are the same.  For efficiency purposes numbers are used to identify things at the lower level.  For example there's a file called NUMBERS.H that is used in all three products.  This file has information like the value of 1 means ALERT, the value of 7 means CAUTION, a value of 18 means DANGER, etc.  This is the stuff that we want to share amongst the different products to maintain consistency.  Say that all three projects are using version 9 of that file.  The Small project makes a change and commits it and created version 10.  The Large project is currently using version 9 but they need to make a change as well.  They will get version 10 and merge their changes, test their changes and test compatibility with the Small project changes then check in version 11.  You now see that the three projects are using different versions but whenever there is a change to the project, there is an effort made to bring everyone to the same point.  So my thoughts was to keep all the shared code in a central project and use "externals".  Again, my understanding of externals may be grossly misunderstood ;-)

Thanks in advance,
Jimmy


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


Re: Is there a better way than using sym links....

Posted by Mark Phippard <ma...@gmail.com>.
Someone is bound to mention that you should post this to users@ list, not dev@.

To answer though, svn:externals is definitely designed to handle this
situation.  It also contains a number of ways to control the version
you get.  You can pin it to a revision, by including the -r N option
in the URL of the property, but the better way is to have the URL
point to a tag.

For example, I use this to pull the JavaHL source code into Subclipse.
 I recently had it "frozen" by pointing to the 1.5.0-alpha2 tag.  But
now, I have modified it to point to the 1.5.x branch so that I can get
the latest version.  I will eventually freeze it to the release tag,
and increment it with each release when I want changes.

--
Thanks

Mark Phippard
http://markphip.blogspot.com/

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