Re: Thoughts about issue #3625 (shelving)

On Fri, Sep 9, 2011 at 10:38, Greg Hudson wrote: > On Fri, 2011-09-09 at 08:09 -0400, Greg Stein wrote: >> Greg Hudson said this is more akin to git stash than branches. I >> haven't used git's stashes to see how it actually differs from >> branches. I guess it is simply that changing branches lea

[PATCH] svn mergeinfo --elide

Users with lots of subtree mergeinfo may want to clean it up by eliding subtree mergeinfo without actually performing a merge. There seem to be scripts floating around that perform this task. But there is no "official" solution yet, it seems. Would it be useful to allow mergeinfo elision to take p

1.7.0-rc3 up for testing / signing

In accordance with my aforementioned intent, I've rolled 1.7.0-rc3 from the latest bits on the 1.7.x branch, and posted them here for testing / signing: http://people.apache.org/~hwright/svn/1.7.0-rc3/ The magic revision is r1167356, please post your signatures at the usual location: http://work.h

Re: bug, svn revert does not restores svn add'ed/rm'ed files

2011/9/9 Rüdiger Meier : > Hi, > > > The subject says it. > > $ svn --version > svn, version 1.6.17 (r1128011) > > $ svn st > $ touch bla > $ svn add bla > A    bla > $ rm bla > $ svn st > !    bla > $ svn revert . > $ svn st > !    bla > > > But this works: > svn revert -R . > 1. That is by desig

Re: 1.7.0 upgrade doesn't properly follow svn:externals

On 2011-09-09, at 11:59 AM, Neels J Hofmeyr wrote: > On 09/09/2011 05:25 PM, Scott Palmer wrote: >> Btw, I haven't had a chance to go back to 1.6 to test - is the issue with >> svn:externals referencing a file fixed? It used to add the file as both an >> external and a regular file so it was co

bug, svn revert does not restores svn add'ed/rm'ed files

Hi, The subject says it. $ svn --version svn, version 1.6.17 (r1128011) $ svn st $ touch bla $ svn add bla Abla $ rm bla $ svn st !bla $ svn revert . $ svn st !bla But this works: svn revert -R . cu, Rudi

Re: 1.7.0 upgrade doesn't properly follow svn:externals

On 09/09/2011 05:59 PM, Neels J Hofmeyr wrote: > On 09/09/2011 05:25 PM, Scott Palmer wrote: >> Btw, I haven't had a chance to go back to 1.6 to test - is the issue with >> svn:externals referencing a file fixed? It used to add the file as both an >> external and a regular file so it was confl

Re: 1.7.0 upgrade doesn't properly follow svn:externals

On 09/09/2011 05:25 PM, Scott Palmer wrote: > Btw, I haven't had a chance to go back to 1.6 to test - is the issue with > svn:externals referencing a file fixed? It used to add the file as both an > external and a regular file so it was conflicting with itself. > > Scott Are you referring to i

Re: Release notes - Older clients and servers interoperate transparently with 1.7 ...

Bert Huijben wrote on Fri, Sep 09, 2011 at 17:13:39 +0200: > > > > -Original Message- > > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > > Sent: vrijdag 9 september 2011 17:09 > > To: Julian Foad > > Cc: Subversion Development > > Subject: Re: Release notes - Older clients and ser

Re: 1.7.0 upgrade doesn't properly follow svn:externals

On 2011-09-09, at 11:14 AM, Neels J Hofmeyr wrote: > On 09/09/2011 04:41 PM, Neels J Hofmeyr wrote: >> And note that a .svn dir remains in XB/XC (seen in the final 'ls') > > I would like to add that 'upgrade' does leave the .svn folders behind > everywhere, but running 'svn info' in the separate

Re: 1.7.0 upgrade doesn't properly follow svn:externals

To end the confusion: .svn folders are left behind only in working copy roots. Dir externals are working copy roots and should therefore have a .svn folder after 'svn upgrade', but it should be a 1.7-.svn. (thx Bert) ~Neels On 09/09/2011 05:14 PM, Neels J Hofmeyr wrote: > On 09/09/2011 04:41 PM,

Re: 1.7.0 upgrade doesn't properly follow svn:externals

On 09/09/2011 04:41 PM, Neels J Hofmeyr wrote: > And note that a .svn dir remains in XB/XC (seen in the final 'ls') I would like to add that 'upgrade' does leave the .svn folders behind everywhere, but running 'svn info' in the separate folders confirms that BX/ is a 1.7 WC and BX/CX is not. ~Nee

RE: Release notes - Older clients and servers interoperate transparently with 1.7 ...

> -Original Message- > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Sent: vrijdag 9 september 2011 17:09 > To: Julian Foad > Cc: Subversion Development > Subject: Re: Release notes - Older clients and servers interoperate > transparently with 1.7 ... > > Julian Foad wrote on Fr

Re: Release notes - Older clients and servers interoperate transparently with 1.7 ...

Julian Foad wrote on Fri, Sep 09, 2011 at 15:53:18 +0100: > The current 1.7 release notes page > says: > > """Compatibility Concerns > >Older clients and servers interoperate transparently with >1.7 servers and clients. [...] > ""

Release notes - Older clients and servers interoperate transparently with 1.7 ...

The current 1.7 release notes page says: """Compatibility Concerns Older clients and servers interoperate transparently with 1.7 servers and clients. [...] """ This could mislead users who are wondering whether TSVN 1.6 and 'svn' 1

Re: 1.7.0 upgrade doesn't properly follow svn:externals

On 09/08/2011 06:21 PM, Scott Palmer wrote: > Just tried 1.7.0RC2 and noticed that bugs with svn upgrade are still present. > > If you have svn:externals in the top level of your working copy they seem to > be converted, but if those external references also use svn:externals then > those nested w

Re: Thoughts about issue #3625 (shelving)

On Fri, 2011-09-09 at 08:09 -0400, Greg Stein wrote: > Greg Hudson said this is more akin to git stash than branches. I > haven't used git's stashes to see how it actually differs from > branches. I guess it is simply that changing branches leaves local > mods, rather than stashing pseudo-reverts t

1.7.-rc3 rolling today

The little voice in my head tells me that we've had several bits get merged to the 1.7.x over the past couple of weeks. To make that voice happy, I plan to roll 1.7.0-rc3 later today. This wouldn't restart the soak, but just gives folks a more up-to-date target to test against. -Hyrum -- uber

Re: Thoughts about issue #3625 (shelving)

Philip Martin wrote on Fri, Sep 09, 2011 at 13:43:35 +0100: > Daniel Shahaf writes: > > > > > > > % cat .subversion/config > > [shorthand] > > s7 = https://svn.apache.org/repos/asf/subversion/branches/1.7.x > > % svn info ^s7/ | grep URL > > URL: https://svn.apache.org/repos/asf/subversion/branc

Re: fs-successor-ids: public API

[ sorry for the delay; didn't want to reply past-midnight ] Branko Čibej wrote on Wed, Sep 07, 2011 at 17:18:11 +0200: > On 07.09.2011 06:05, Branko Čibej wrote: > > What specific questions are we likely to ask about a particular node > > revision? The obvious ones are: > > > > * when was this "

Re: Thoughts about issue #3625 (shelving)

Daniel Shahaf writes: > > > % cat .subversion/config > [shorthand] > s7 = https://svn.apache.org/repos/asf/subversion/branches/1.7.x > % svn info ^s7/ | grep URL > URL: https://svn.apache.org/repos/asf/subversion/branches/1.7.x > > If we implemented that would substitution occur in the client

Re: Thoughts about issue #3625 (shelving)

Greg Stein wrote on Fri, Sep 09, 2011 at 08:09:51 -0400: > On Fri, Sep 9, 2011 at 07:05, Daniel Shahaf wrote: > > Once we have a .svn area shared by multiple working copies, though, > > something like that would be useful --- perhaps, 'switch this wc to > > the most recent snapshot of branches/fs-

Re: Thoughts about issue #3625 (shelving)

On Fri, Sep 9, 2011 at 07:05, Daniel Shahaf wrote: > Greg Stein wrote on Thu, Sep 08, 2011 at 23:43:04 -0400: >> Also consider: the shelves can then act as multiplexors for the >> working copy. You could have one shelf for trunk, one for >> branches/1.7.x, one for 1.6.x, one for branches/fs-succes

Re: Thoughts about issue #3625 (shelving)

On Fri, Sep 9, 2011 at 00:44, Greg Hudson wrote: > On Thu, 2011-09-08 at 23:43 -0400, Greg Stein wrote: >> I've had to use git lately, and our shelves could almost look like >> git's branches. Swap around among them based on what you're doing at >> the time. > > I think this is closer to git's "st

Re: Thoughts about issue #3625 (shelving)

Greg Stein wrote on Thu, Sep 08, 2011 at 23:43:04 -0400: > On Thu, Sep 8, 2011 at 19:33, Daniel Shahaf wrote: > > Stefan Sperling wrote on Thu, Sep 08, 2011 at 00:36:05 +0200: > >... > >> Sure. But in the initial implementation we could just restore the former > >> working copy state, including mi

Re: Thoughts about issue #3625 (shelving)

Greg Stein wrote on Thu, Sep 08, 2011 at 23:43:04 -0400: > Also consider: the shelves can then act as multiplexors for the > working copy. You could have one shelf for trunk, one for > branches/1.7.x, one for 1.6.x, one for branches/fs-successor-ids, and > for some trunk changes that you set aside.