You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Walter Nicholls <wa...@cornerstone.co.nz> on 2004/04/01 21:14:53 UTC

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 ..

Re: Roadmap for 1.1

Posted by Sander Rijken <sr...@sander.yi.org>.
You can only edit one instance of foo.txt at once. the other branches
are totally seperate files.
You branch at, say revision 10, when the trunk moves to revision 11, the
branch remains unchanged, so theres no need to lock it.

Sander

On Fri, 2004-04-02 at 18:02, C.A.T.Magic wrote:
> Simon Raess wrote:
> 
>  >> 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)
> 
> I have a question on locking and svn in general:
> when locking a single file, you would only lock
> 
> for example
> 
>    /trunk/foo.txt
> 
> but all other branches that contain this file
> 
>    /bar/Branch01/foo.txt
>    /bar/Branch02/foo.txt
> 
> would remain unlocked, since svn is unable
> to detect that these are branches and are related.
> 
> Or do I misunderstand that?
> 
> ======
> c.a.t.
> 
> 
> ---------------------------------------------------------------------
> 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

Re: Roadmap for 1.1

Posted by "C.A.T.Magic" <c....@gmx.at>.
Simon Raess wrote:

 >> 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)

I have a question on locking and svn in general:
when locking a single file, you would only lock

for example

   /trunk/foo.txt

but all other branches that contain this file

   /bar/Branch01/foo.txt
   /bar/Branch02/foo.txt

would remain unlocked, since svn is unable
to detect that these are branches and are related.

Or do I misunderstand that?

======
c.a.t.


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

Re: Roadmap for 1.1

Posted by Simon Raess <co...@gmx.ch>.
Am 01.04.2004 um 23:14 schrieb Walter Nicholls:

> 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)

Aren't advisory locks all that's needed. Exclusive locks may work when 
the users are all working at the same location but it does not work 
when developers are situated all over the world (as usual in opensource 
projects). Even if users are all at the same location there exist some 
problems. Imagine what happens if somebody locks a file and leaves for 
holidays... (I know, there are admin commands)

I imagine something like edit/unedit (or lock/unlock or ...). Before I 
use a file that should be locked (specified by a svn property?), I call

$ svn edit myfile.txt

If somebody else is already editing the file I get a message that tells 
me who is editing the file. I can then talk with this person (maybe he 
has forgotten to release the lock...). If I'm really sure what I'm 
doing I could specify a command line option that overrides the warning 
(--force?).

Let's say I'm the first person who wants to edit that file. After my 
work is completed, I simple type

$ svn unedit myfile.txt

and the lock is released.


Isn't that all that's needed? If not, please enlighten me ;-)

Simon


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

Re: Roadmap for 1.1

Posted by Shawn Harrison <ha...@tbc.net>.
I'll put in my two cents for shared/advisory locking. I am planning to move
an editing team of approximately 50 people into using Subversion, followed
in time by the rest of the design and publication workgroups in a
medium-sized publishing house. Shared/advisory locking would be a great
benefit in this environment, in which everything is in binary files. There
are many cases where you want to ensure that two people are not editing the
same document at the same time, because merging is far from automatic.
Communicating back and forth by email, and/or logging something in the
project management database online, is helpful, but error-prone.
Shared/advisory locking would put Subversion into a position to be useful in
thousands of corporate and workgroup settings where version control is
desired, but concurrent editing is undesirable.

Shawn Harrison

----- Original Message ----- 
From: "Walter Nicholls" <wa...@cornerstone.co.nz>
To: <us...@subversion.tigris.org>
Cc: <kf...@collab.net>
Sent: Thursday, April 01, 2004 3:14 PM
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 ..

RE: Roadmap for 1.1

Posted by Barry Scott <ba...@barrys-emacs.org>.
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

RE: Roadmap for 1.1

Posted by Ian Brockbank <ia...@wolfsonmicro.com>.
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.

RE: Roadmap for 1.1

Posted by Ian Brockbank <ia...@wolfsonmicro.com>.
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