SourceSafe has shared files support and we encountered many show stopper
issues when its used. The big problem is that you get unexpected changes
in code that you might have thought was code frozen.
You can solve this problem without much overhead without using shared
files. I'd release Common (tag it) then build specific targets against the
tagged common. If you have to fix common for a specific target you
create a new tag of common and critically don't invalidate any release
you made for another target against an earlier tar of common. You can
also avoid having to get all targets working at the same time if you
are resource limited.
Divide and conquer is better the sharing in my experience.
Barry
At 06-04-2004 16:03, Ian Brockbank wrote:
>Hi All,
>
>I would also like to vote for work on shared files. Our scenario:
>
> - We have to support multiple operating systems and multiple
> hardware platforms.
> - Each OS/hardware combination gets packaged separately to go
> to different customers.
> - There are various components common to all OSes and all platforms.
> - A "release" is a full set of OS/hardware combinations.
>
>We would like to be able to have the various components and build them up
>automatically from the SCM system - we use CVS modules at present. We would
>also like to be able to tag the set all together.
>
>For example, say we have the following:
>
>trunk/Core
> inc/
> src/
> doc/
> file1
>trunk/WinCE
> OS_Layer/
> Drivers/
>trunk/PalmOS
> OS_Layer/
> Drivers/
>trunk/XScale
>trunk/Geode
>
>We would like to be able to build up
>
>trunk/API/WinCE_XScale
> Drivers (alias of trunk/WinCE/Drivers)
> API
> inc/
> src/
> doc/
> file1
> OS_Layer (alias of trunk/WinCE/OS_Layer)
> Platform (alias of trunk/XScale)
>
>trunk/API/WinCE_Geode
> Drivers (alias of trunk/WinCE/Drivers)
> API
> inc/
> src/
> doc/
> file1
> OS_Layer (alias of trunk/WinCE/OS_Layer)
> Platform (alias of trunk/Geode)
>
>trunk/API/Palm_XScale
> Drivers (alias of trunk/Palm/Drivers)
> API
> inc/
> src/
> doc/
> file1
> OS_Layer (alias of trunk/Palm/OS_Layer)
> Platform (alias of trunk/XScale)
>
>trunk/API/Palm_Geode
> Drivers (alias of trunk/Palm/Drivers)
> API
> inc/
> src/
> doc/
> file1
> OS_Layer (alias of trunk/Palm/OS_Layer)
> Platform (alias of trunk/Geode)
>
>Then when we did a release we would create a tag from trunk/API and
>export it and do our testing for each platform combination.
>
>However, we would need to be able to work in one of the API subdirectories
>(e.g. API/Palm_XScale) and get our changes to the common directories
>propagated to all versions (we need them to stay in synch).
>
>At present we plan to use svn:externals to achieve this, e.g. with the
>following externals on API/Palm_XScale:
>
>===
>Drivers http://subversion/repos/trunk/PalmOS/Drivers
>API http://subversion/repos/trunk/Core
>API/OS_Layer http://subversion/repos/trunk/PalmOS/OS_Layer
>API/Platform http://subversion/repos/trunk/XScale
>===
>
>but there are several limitations which will cause us problems:
> - we can't tag properly, because the svn:externals are absolute paths
> - we can't branch properly, likewise
> - the svn:externals handling doesn't always seem happy with the
> multiple layers (the fact that OS_Layer is a subdirectory of API)
> - if we have to move our repository, all our externals will become
> invalid
>
>And WinCE forces another gotcha on us - its makefiles are completely
>different to the makefiles on other platforms (to the point that the two are
>irreconcilable), so we really need file-level links rather than just
>directory-level so that we can pick up the build files appropriate to the
>given OS.
>
>If we could specify relative links within the repository, which get
>maintained on branches and tags, that would help - e.g. our link for
>API/WinCE_XScale could be
>
>===
>Drivers ../../WinCE/Drivers
>API ../../Core
>API/OS_Layer ../../WinCE/OS_Layer
>API/Platform ../../XScale
>makefile ../../WinCE/Build/makefile
>API/makefile ../../WinCE/Build/API/makefile
>API/src/makefile ../../WinCE/Build/API/src/makefile
>API/Platform/makefile ../../WinCE/Build/XScale/makefile
>===
>
>Another thought (which would help the guy doing the Linux work, too) - it
>would be really nice to be able to build up a fileset from a base set of
>files - Linux kernel, WinCE BSP, Palm DAL - with specific overrides for the
>minimal set of files which have actually been changed. If you take the
>links above as priority ordered, I could create a BSP for a platform called
>(let's say) "Jenie" which uses an XScale PXA255 on WinCE by creating a
>directory
>
>trunk/BSPs/Base/PXA255 (containing the base BSP for the PXA255)
>
>and
>
>trunk/BSPs/Jenie
>
>containing the following links:
>
>===
>Jenie/Drivers ../../API/WinCE_XScale
>Jenie ../../BSPs/Base/PXA255
>===
>
>In case of any conflicts, ../../API/WinCE_XScale would win. Checkins on
>conflicting directories would go to ../../API/WinCE_XScale. In other words,
>the ambiguities from having two repository locations mapping to one file
>system location are explicitly up to me to resolve with the ordering of my
>mappings.
>
>Cheers,
>
>Ian Brockbank C.Eng. MBCS
>Applications Software Engineer
>e: ian.brockbank@wolfsonmicro.com / apps@wolfsonmicro.com
>scd: ian@scottishdance.net
>t: +44 131 272 7145
>f: +44 131 272 7001
>
>
>
>
> > -----Original Message-----
> > From: Walter Nicholls [mailto:walter.nicholls@cornerstone.co.nz]
> > Sent: 01 April 2004 22:15
> > To: users@subversion.tigris.org
> > Cc: kfogel@collab.net
> > Subject: RE: Roadmap for 1.1
> >
> > I trying to prioritise features for 1.1, how about looking at the
> > subversion development process from the point of view of not adding
> > *features* but adding *users*
> >
> > For example:
> >
> > Subversion 1.0 - woo existing CVS users
> > Subversion 1.1 - woo existing SourceSafe users
> > .. etc ..
> >
> > From my point of view, I'd rather have a Subversion 1.1 sooner (eg 6
> > months) that has fewer features but addresses a specific user group
> > completely, than a Svn 1.1 later (eg 18 months)that has lots
> > of features
> > but *still* doesn't enable people to migrate to it. Obviously as a
> > SourceSafe user (and despiser) I would like that user group to include
> > me, but actually I think there are some good reasons for
> > targetting them
> > anyway.
> >
> > I haven't included "users new to source control" above
> > because they can
> > come in at any time. Examples of other user groups to consider (post
> > 1.1) might be arch users, clearcase, people who demand the
> > repository is
> > stored in a SQL database ... I don't think anyone considers
> > any of those
> > to be on the critical hit list.
> >
> > Now my examples are pretty arbitary, but my point is that if you only
> > scratch some of everyone's itches, noone will be satisfied.
> > Obviously I
> > am majorly biased (see www.sourcecross.org) but apart from doing
> > everyone a favour from making sourcesafe unnecessary, being a viable
> > alternative to sourcesafe will attract a large community, especially
> > Windows users who are a very large body of people. (I could also spin
> > that a little and suggest (very <tic>) that Windows users are
> > primarily
> > immature development shops that may mature in future and buy
> > SourceCast
> > <g,d&r from all those mature Windows developers out there, me
> > included!>)
> >
> > Perhaps more to the point, SourceSafe users are going to be
> > in a mind to
> > switch. Clearcase users probably aren't (unless they have changed jobs
> > and want to set up a similar system without the licence fees), and I
> > don't think I need to say anything about Arch devotees on this list...
> >
> > Anyway to get to the point.
> >
> > I think the main SourceSafe features that Subversion 1.0 does
> > not cover
> > are:
> > 1. Locking (both exclusive and advisory)
> > 2. Shared files (same file in two repository locations)
> > 3. Labels (named revisions)
> >
> > There are some others which I don't think are that big a deal or the
> > workarounds are near trivial: cloaked projects, shadow folders (use
> > post-commit hook), access rights (mod_svn_authz does me fine)
> >
> > 1. Locking
> > Well, you're dealing with that. Note that the lockingplan.txt when I
> > read seemed to focus on Exclusive locks only - we need shared/advisory
> > locks as well (and locks must have the user recorded against
> > them or the
> > advice is not so useful)
> >
> > 2. Shared files
> > This itch is *almost* satisfied by svn:externals, but not quite. I
> > don't think it would be difficult to make svn:externals work
> > safisfactorily - just need commits to go to the right place
> > in the right
> > repository.
> > As far as shared files vs shared directories, I actually prefer the
> > directory anyway.
> >
> > 3. Labels
> > This isn't a big deal for me, and I think placing a label property on
> > the revision is perfectly adequate. (Other people may have
> > other ideas,
> > wanting to say "svn co -r SUBVERSION_1_1_0_beta1" perhaps.)
> >
> > ----------
> > Of the other features
> >
> > * I18n is very important, if scary (Obviously the current users all
> > have no trouble with English, so the support can all be channelled
> > through English speaking channels - ie users@ mailing list)
> > * The release procedures do need tightening: we don't need
> > things like
> > the 1.0.0 broken python on Windows, and the delay in getting Windows
> > 1.0.1 out wasn't good either.
> > * Working towards anything that improves integrity of historical
> > information (I think I mean "renames"!)
> > * Work towards anything that makes it easier to resolve branching /
> > merging ("history-sensitive merges?")
> >
> > I don't have voting rights, so this is best I can do to influence
> > people...
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
> >
> > ______________________________________________________________
> > __________
> > This email has been scanned for all viruses by the MessageLabs Email
> > Security System.
> > ______________________________________________________________
> > __________
> >
>
>
>Wolfson Microelectronics plc
>www.wolfsonmicro.com
>T +44 131 272 7000
>F +44 131 272 7001
>Registered in Scotland 89839
>
>This message may contain confidential or proprietary information. If you
>receive this message in error, please immediately delete it, destroy all
>copies of it and notify the sender. Any views expressed in this message
>are those of the individual sender, except where the message states
>otherwise. We take reasonable precautions to ensure our Emails are virus
>free. However, we cannot accept responsibility for any virus transmitted
>by us and recommend that you subject any incoming Email to your own virus
>checking procedures.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 9 00:42:55 2004