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
Received on Tue Apr 6 17:04:05 2004