Hi All,
I've been thinking about this a bit more, and I think I have two concrete
proposals:
1: Allow relative paths in svn:externals.
From previous postings, I gather that a path of the form ../bar is easier to
work with than absolute paths from the root of the repository. That would
do me fine.
I have updated #1336 with our use case as below. See
http://subversion.tigris.org/issues/show_bug.cgi?id=1336
2: Allow multiple svn:externals to map to the same directory
This would be useful for (e.g.) modifications to kernels. Say I am working
on half a dozen files in a Linux driver. It would be useful to be able to
set up a mapping e.g.
Linux http://someserver/linuxkernel
Linux http://localserver/repos/my-skeleton-kernel
and have any files in http://localserver/repos/my-skeleton-kernel overwrite
the same files from http://someserver/linuxkernel, but leave the rest of the
files from http://someserver/linuxkernel as they are. I would then just
check in my modified files to the appropriate directories in
my-skeleton-kernel.
How to resolve ambiguities and clashes? Take the last one which matches.
This could apply for checkins as well.
This might fall out of the fix for #1788 (see
http://subversion.tigris.org/issues/show_bug.cgi?id=1788), but I've added a
new enhancement request #1820 in case it doesn't. I also include more
detail and examples. See
http://subversion.tigris.org/issues/show_bug.cgi?id=1820. This would also
solve my build file problem - again, more details in #1820.
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: Ian Brockbank [mailto:ian.brockbank@wolfsonmicro.com]
> Sent: 06 April 2004 16:03
> To: users@subversion.tigris.org
> Subject: RE: Roadmap for 1.1
>
> 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 Wed Apr 7 13:53:44 2004