Re: Thoughts about issue #3625 (shelving)

[Greg Stein]

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 leaves local
>> mods, rather than stashing pseudo-reverts the local mods.
>
> * Branches record tree states, while stashes record changesets as
> applied to the working copy and index.  You can "git stash", "git
> checkout branchname", and "git stash pop" the changeset such that it is
> now applied against the new branch, if it applies cleanly.  You can do
> similar things with branches using rebase, but the sequence of
> operations would be different and more complicated.
>
> * Stashes are a working copy feature, and aren't part of the history
> model.  This isn't necessarily an interesting distinction for us, but it
> has some consequences within the universe of git--a subsidiary
> repository's git fetch won't retrieve stashes, they won't be in the
> target space of commit specifiers, you don't have to create commit
> messages for them, etc..
>
> Stashes don't make git more expressive than local branches and rebase,
> but in some ways it's a useful UI concept to keep them separate.

Thanks for the extra detail!

>> Mercurial calls it shelving.
>
> Aha.  I'll note that shelving isn't a core feature of Mercurial but an
> extension.  Even if there are aliases so the command is accessible via
> both names, the feature needs to have a primary name (which will be how
> it's documented in the book, etc.).

Yup.

$ svn praise --help
blame (praise, annotate, ann): Output the content of specified files or
URLs with revision and author information in-line.
usage: blame TARGET[@REV]...
...

I will be lobbying for 'stash' as primary, and 'shelve' as an alias.

Cheers,
-g

[PATCH] svn mergeinfo --elide

[Stefan Sperling]

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 place outside
the context of a merge? The patch below makes it possible to trigger
mergeinfo elision by running 'svn mergeinfo --elide'.

It seems that the elision algorithm is very basic at the moment,
which prevents this from being really useful. Subversion only elides
mergeinfo which exactly matches the mergeinfo of a parent.
It doesn't perform elision if mergeinfo on the parent covers a
greater range of revisions than the mergeinfo on the child.

Is this deliberate?

For instance:

r3 changed '/branch/gamma'.
This is merged into '/trunk', as follows:

$ svn merge --reintegrate ^/branch/gamma gamma
--- Merging differences between repository URLs into 'gamma':
Ugamma/delta
--- Recording mergeinfo for merge between repository URLs into 'gamma':
 U   gamma
$

Nothing further happens on the branch.
Later, we merge the entire branch (a no-op merge):

$ svn merge --reintegrate ^/branch
--- Recording mergeinfo for merge between repository URLs into '.':
 U   .
$

Note that no elision took place.
Now we have the following mergeinfo which will not elide:

Properties on '.':
  svn:mergeinfo
  /branch:2-4
Properties on 'gamma':
  svn:mergeinfo
  /branch:2-3

The following mergeinfo will elide:

Properties on '.':
  svn:mergeinfo
  /branch:2-4
Properties on 'gamma':
  svn:mergeinfo
  /branch:2-4

So the user is required to run no-op merges on subtrees in order
to elide mergeinfo from subtrees. This can be quite tedious.

It should be safe elide mergeinfo from 'gamma' to the root of the
working copy. The mergeinfo on the parent is inheritable and a
superset of the mergeinfo on 'gamma'.

If the elision algorithm supported elision of mergeinfo which
is a proper subset of the mergeinfo in a parent, cleaning up
subtree mergeinfo would become a lot more easier than it is now.

Would it be a good idea to commit this patch and wait for the
elision algorithm to improve? Having 'svn mergeinfo --elide'
might make it a bit easier to perform ad-hoc testing while
improving the algorithm.

This thread on users@ inspired the idea:
http://svn.haxx.se/users/archive-2011-09/0101.shtml

[[[
Teach the 'svn mergeinfo' command to elide mergeinfo.

In some situations it can be useful to remove redundant mergeinfo
without actually running a merge.

Add a new option --elide to 'svn mergeinfo' which causes it
to elide mergeinfo instead of displaying it. The new --elide
option is mutually exclusive with the --show-revs option.

* subversion/include/svn_client.h
  (svn_client_elide_subtree_mergeinfo): New.

* subversion/svn/cl.h
  (svn_cl__opt_state_t): New option ELIDE_MERGEINFO.

* subversion/svn/mergeinfo-cmd.c
  (svn_cl__mergeinfo): If the --elide option was given, elide
   mergeinfo within the specified working copy path instead
   of displaying mergeinfo, and default to depth 'infinity'.
   If the working copy path was not given, default to the
   current directory.

* subversion/svn/main.c
  (svn_cl__longopt_t, svn_cl__options): New option --elide.
  (svn_cl__cmd_table): Update help for 'svn mergeinfo'.
  (main): Handle new --elide option. Disallow --elide and
   --show-revs being used together.

* subversion/libsvn_client/mergeinfo.c
  (elide_subtree_mergeinfo_baton, elide_subtree_mergeinfo_cb,
   elide_subtree_mergeinfo_locked, svn_client_elide_subtree_mergeinfo): New.
]]]

Index: subversion/include/svn_client.h
===
--- subversion/include/svn_client.h (revision 1167379)
+++ subversion/include/svn_client.h (working copy)
@@ -3587,6 +3587,15 @@ svn_client_mergeinfo_log_eligible(const char *path
   svn_client_ctx_t *ctx,
   apr_pool_t *pool);
 
+/* Try to elide mergeinfo on working copy node @a local_abspath
+ * and children within the specified @a depth.
+ * Use @a scratch_pool for any temporary allocations. */
+svn_error_t *
+svn_client_elide_subtree_mergeinfo(const char *local_abspath,
+   svn_depth_t depth,
+   svn_client_ctx_t *ctx,
+   apr_pool_t *scratch_pool);
+
 /** @} */
 
 /**
Index: subversion/svn/cl.h
===
--- subversion/svn/cl.h (revision 1167379)
+++ subversion/svn/cl.h (working copy)
@@ -230,6 +230,7 @@ typedef struct svn_cl__opt_state_t
   svn_boolean_t internal_diff;/* override diff_cmd in config file */
   svn_boolean_t use_git_diff_format; /* Use git's extended diff format */
   svn_boolean_t allow_mixed_rev; /* Allow operation on mixed-revision WC */
+  svn_boolean_t elide_mergeinfo; /* Elide mergeinfo. */
 } sv

1.7.0-rc3 up for testing / signing

[Hyrum K Wright]

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.hyrumwright.org/pub/svn/collect_sigs.py

This is not intended to restart the soak period, but rather get
additional testing for fixes merged since rc2 and give folks an
updated milestone to test against.

-Hyrum


-- 

uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/

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

[Konstantin Kolinko]

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 design: revert operation by default is not recursive.

E.g. if I edit a file, calling "svn revert" on its parent directory
won't revert the file, and "svn revert . --depth infinity" will revert
it. You are observing the same for an added file.

Consider if you have changes some property on the directory (e.g.
svn:ignore or svn:mergeinfo) and want to revert it.  The only way is
to call "svn revert" on this directory, and that is why it should not
be recursive.

BTW, I tested your commands and behaviour in 1.7 is the same.

2. This thread belongs to the users@ list, not dev@.

Best regards,
Konstantin Kolinko

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

[Scott Palmer]

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 conflicting with itself.
>> 
>> Scott
> 
> Are you referring to issue #4000?
> http://subversion.tigris.org/issues/show_bug.cgi?id=4000
> 
> If not, do you have a link or a reproduction script?
> 
> Thanks,
> ~Neels

It may be related, and possibly it fixes the issue I encountered, but it is not 
exactly the same.  What happened in my case is that a file external was in my 
1.6 working copy and the svn upgrade appeared to add it as a "first-class node" 
while leaving it as an external as well.  From that point on "svn update" would 
complain about overwriting the first-class node when attempting to update the 
external reference.

Sorry I don't have a reproduction script - I'm not currently set up to run both 
1.6 and 1.7 to build one.

I suppose you can start with the first part of the script in issue #4000 but 
use svn 1.6 up to the point of creating the wWC with the file external and 
checking it out.  Then just switch to 1.7 and attempt an upgrade and update.

Scott

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

[Rüdiger Meier]

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

[Neels J Hofmeyr]

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 conflicting with itself.
>>
>> Scott
> 
> Are you referring to issue #4000?
> http://subversion.tigris.org/issues/show_bug.cgi?id=4000

No, you are referring to issue #4015
http://subversion.tigris.org/issues/show_bug.cgi?id=4015

We are (read: philip is) currently in the process of fixing it, and it
hopefully will be fixed in RC3.

~Neels



signature.asc
Description: OpenPGP digital signature

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

[Neels J Hofmeyr]

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 issue #4000?
http://subversion.tigris.org/issues/show_bug.cgi?id=4000

If not, do you have a link or a reproduction script?

Thanks,
~Neels



signature.asc
Description: OpenPGP digital signature

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

['Daniel Shahaf']

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 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. [...]
> > > """
> > >
> > > This could mislead users who are wondering whether TSVN 1.6 and 'svn'
> > > 1.7 clients will interoperate transparently on the same WC.  Would this
> > > be better?
> > >
> > 
> > What about 1.6 and 1.7 servers interoperating on the same repository?
> 
> 1.7 didn't bump the repository format, so what would you want to write about
> this?

That 1.6 and 1.7 servers interoperate.

That 1.x and 1.y servers interoperate as long as the repository hasn't
been upgraded.

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

[Scott Palmer]

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 folders confirms that BX/
> is a 1.7 WC and BX/CX is not.
> 
> ~Neels

I was actually wondering when you mentioned it if .svn folders weren't expected 
to be in "external" working copies.  I'm just so used to how Subversion has 
worked in the past.  I expect any sub-tree of my working copy to function as a 
working copy even if it was moved elsewhere.  While it shouldn't be a problem 
to come around to the new way, I though that externals might somehow be an 
exception - as if they were an independent checkout.

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

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

[Neels J Hofmeyr]

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, 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.
> 
> ~Neels
> 



signature.asc
Description: OpenPGP digital signature

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

[Neels J Hofmeyr]

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.

~Neels



signature.asc
Description: OpenPGP digital signature

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

[Bert Huijben]

> -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 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. [...]
> > """
> >
> > This could mislead users who are wondering whether TSVN 1.6 and 'svn'
> > 1.7 clients will interoperate transparently on the same WC.  Would this
> > be better?
> >
> 
> What about 1.6 and 1.7 servers interoperating on the same repository?

1.7 didn't bump the repository format, so what would you want to write about
this?

Bert

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

[Daniel Shahaf]

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. [...]
> """
> 
> This could mislead users who are wondering whether TSVN 1.6 and 'svn'
> 1.7 clients will interoperate transparently on the same WC.  Would this
> be better?
> 

What about 1.6 and 1.7 servers interoperating on the same repository?

> """Older clients interoperate transparently with 1.7 servers, and
>older servers interoperate transparently with 1.7 clients. [...]
> """
> 
> - Julian
> 
> 

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

[Julian Foad]

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.7 clients will interoperate transparently on the same WC.  Would this
be better?

"""Older clients interoperate transparently with 1.7 servers, and
   older servers interoperate transparently with 1.7 clients. [...]
"""

- Julian

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

[Neels J Hofmeyr]

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 working copies are not upgraded.
> 
> Is anyone else seeing this?

Hi Scott,

thanks for the report! I can reproduce the problem with attached test
script. (The script uses my local bin/svn paths of built Subversion
versions, so I also attached a screenshot output.)

I am "moving" this discussion to the dev@ list, please reply there.

Note that the test upgrades the external dir XB, but fails to upgrade the
nested external dir XB/XC:

[[[
...
Fetching external item into 'XB/XC'
AXB/XC/c
Updated external to revision 1.
...
+ svn upgrade
Upgraded '.'
Upgraded 'B'
Upgraded 'C'
Upgraded 'XB'
Upgraded 'B/XC'
]]]

And note that a .svn dir remains in XB/XC (seen in the final 'ls')

I'll see if I can find a solution.

~Neels
#!/usr/bin/env bash

## TO MAKE THIS RUN YOUR CUSTOM COMPILED SVN, two simple options:
## 1. Adjust your PATH to point at your custom installed location:
##  export PATH="$HOME/prefix/svn_trunk/bin:$PATH"
## OR
## 2. Uncomment the four lines below to use aliases into your
##built source tree. The next line is the only line you should
##need to adjust.
# SVNDIR=/path/to/built_subversion_source_tree
# function svn() { "$SVNDIR/subversion/svn/svn" "$@"; }
# function svnserve() { "$SVNDIR/subversion/svnserve/svnserve" "$@"; }
# function svnadmin() { "$SVNDIR/subversion/svnadmin/svnadmin" "$@"; }

set -e

svn --version

# current path points at Subversion 1.7.x. Change that to 1.6.x:
OLD_PATH="$PATH"
export PATH="$HOME/pat/1.6.17/prefix/bin:$OLD_PATH"
svn --version | grep version


BASE="$(mktemp -d "/tmp/$(basename "$0").XXX")"
echo "BASE = $BASE"
REPOS="$BASE/repos"
WC="$BASE/wc"
URL="file://$REPOS"
svnadmin create "$REPOS"

# enable all revprop changes
cat > "$REPOS/hooks/pre-revprop-change" < a
mkdir B
echo b > B/b
mkdir C
echo c > C/c
svn add a B C
svn ps svn:externals "^/C XC" B
svn ps svn:externals "^/B XB" .
svn ci -mm

svn up

# back to using Subversion 1.7.x
set +x
export PATH="$OLD_PATH"
set -x
svn --version | grep version

svn upgrade

ls -a XB/XC/

## END
set +x
echo "BASE = $BASE"
svn, version 1.7.0-dev (under development)
   compiled Sep  7 2011, 21:15:48

Copyright (C) 2011 The Apache Software Foundation.
This software consists of contributions made by many people; see the NOTICE
file for more information.
Subversion is open source software, see http://subversion.apache.org/

The following repository access (RA) modules are available:

* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
  - handles 'http' scheme
  - handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme

svn, version 1.6.17 (r1128011)
Subversion is open source software, see http://subversion.apache.org/
BASE = /tmp/palmer.AtX
+ svn --version
+ grep version
svn, version 1.6.17 (r1128011)
Subversion is open source software, see http://subversion.apache.org/
+ svn co -q file:///tmp/palmer.AtX/repos /tmp/palmer.AtX/wc
+ cd /tmp/palmer.AtX/wc
+ echo a
+ mkdir B
+ echo b
+ mkdir C
+ echo c
+ svn add a B C
A a
A B
A B/b
A C
A C/c
+ svn ps svn:externals '^/C XC' B
property 'svn:externals' set on 'B'
+ svn ps svn:externals '^/B XB' .
property 'svn:externals' set on '.'
+ svn ci -mm
Sending.
Adding B
Adding B/b
Adding C
Adding C/c
Adding a
Transmitting file data ...
Committed revision 1.
+ svn up

Fetching external item into 'XB'
AXB/b
 U   XB

Fetching external item into 'XB/XC'
AXB/XC/c
Updated external to revision 1.

Updated to revision 1.

Fetching external item into 'B/XC'
AB/XC/c
Updated external to revision 1.

Updated to revision 1.
+ set +x
+ svn --version
+ grep version
svn, version 1.7.0-dev (under development)
Subversion is open source software, see http://subversion.apache.org/
+ svn upgrade
Upgraded '.'
Upgraded 'B'
Upgraded 'C'
Upgraded 'XB'
Upgraded 'B/XC'
+ ls -a XB/XC/
.
..
c
.svn
+ set +x
BASE = /tmp/palmer.AtX


signature.asc
Description: OpenPGP digital signature

Re: Thoughts about issue #3625 (shelving)

[Greg Hudson]

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 the local mods.

* Branches record tree states, while stashes record changesets as
applied to the working copy and index.  You can "git stash", "git
checkout branchname", and "git stash pop" the changeset such that it is
now applied against the new branch, if it applies cleanly.  You can do
similar things with branches using rebase, but the sequence of
operations would be different and more complicated.

* Stashes are a working copy feature, and aren't part of the history
model.  This isn't necessarily an interesting distinction for us, but it
has some consequences within the universe of git--a subsidiary
repository's git fetch won't retrieve stashes, they won't be in the
target space of commit specifiers, you don't have to create commit
messages for them, etc..

Stashes don't make git more expressive than local branches and rebase,
but in some ways it's a useful UI concept to keep them separate.

> Mercurial calls it shelving.

Aha.  I'll note that shelving isn't a core feature of Mercurial but an
extension.  Even if there are aliases so the command is accessible via
both names, the feature needs to have a primary name (which will be how
it's documented in the book, etc.).

1.7.-rc3 rolling today

[Hyrum K Wright]

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

-- 

uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/

Re: Thoughts about issue #3625 (shelving)

[Daniel Shahaf]

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/branches/1.7.x
> >
> > 
> 
> If we implemented that would substitution occur in the client or the
> libraries?  Would it apply to svn:externals?

We could break the API into two levels: a lower-level API that simply
exposes a hash of shortnames -> URLs and a higher-level API that takes
a URL such as ^foo/trunk and returns an absolute URL.

I don't think having ^s7/ URLs in externals is a good idea as it makes
the property values dependent upon ~/.subversion/config entries.  We
might want to have ^svn:foo/some/dir/here/ style URLs too, though, where
^svn:foo/ are expanded, not by looking for a key called 'svn:foo' in the
config hash, but by some other means specific to each svn:%s key.

Re: fs-successor-ids: public API

[Daniel Shahaf]

[ 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 "thing" created? (-> path@rev)
> >   * when was it deleted? (-> path@rev)
> >   * what is its immediate predecessor? (-> path@rev)
> >   * what are its immediate successors? (-> list of path@rev, includes
> > copied-to)
> >   * what is the its PATH at REV1? (-> path)
> >   * where did its content come from? (-> list of path@rev, includes
> > merged-from)
> >   * where did its content go to? (-> list of path@rev, includes merged-to)
> 
> Here are some more:
> 
>   * are PATH1@REV1 and PATH2@REV2 the same thing?
>   * is PATH2@REV2 a successor of PATH1@REV1?
>   * ditto for predecessors
> 

Thanks for the feedbacks.  It seems the questions here are, largely,
"What is the next interesting thing that happens to PATH@REV" (eg,
a copy, a delete, a text mod, or a merge), in either direction.

I think the next question in this area will be what parts of this should
be in the repos layer and which should be in the FS backends.  Personally
I plan to revisit these questions after the implementation of succcessors
cache reading in FSFS is done.

> Note that the first and second questions are not necessarily equivalent.
> "The same thing" implies there are no copies in the succession from
> PATH1@REV1 to PATH2@REV2, whereas the answer to the second question
> would include copies.
> 
> Incidentally, this is where "branch" and "copy" are fundamentally
> different: a branch maintains the node identity, a copy creates a new node.
> 
> -- Brane
> 

Thanks,

Daniel

Re: Thoughts about issue #3625 (shelving)

[Philip Martin]

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 or the
libraries?  Would it apply to svn:externals?

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com

Re: Thoughts about issue #3625 (shelving)

[Daniel Shahaf]

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-progress that you have in .svn'.
> > ('svn switch ^/subversion/branches/fs-progress@WCDB', or perhaps give it
> > a symbolic name (and make 'update' change what the symbolic name points
> > to).
> 
> I've found that git has symbolic names for repositories. Kinda handy
> to refer to "myrepos" vs "upstream", rather than remembering the URLs.
> 



% 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



> Cheers,
> -g

Re: Thoughts about issue #3625 (shelving)

[Greg Stein]

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-successor-ids, and
>> for some trunk changes that you set aside.
>
> Why do you have separate NODES and SHELF_NODES tables then?  I'd
> intuitively expect the NODES table to be replaced by the SHELF_NODES
> table, i.e., every working copy state --- including the one immediately
> after 'checkout' --- becomes a shelf.  (Though perhaps the first shelf
> is 'special' in one or more to-be-determined ways.)

True! Could certainly do that. A little trickier to upgrade, and lots
queries would need to be altered... but sure. We'd only have to take
that hit once, and add a 'shelf_id' to the NODES table.

>> 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.
>
> Usually want to hack on them concurrently --- i.e., to create a backport
> branch and 'make check' it while at the same time adding it to STATUS
> and looking at wc-queries.sql on trunk for someone on IRC.  Having
> multiple shelves within a single working copy isn't good enough for
> such use.

Yup. Just saying.

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 the local mods.

> 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-progress that you have in .svn'.
> ('svn switch ^/subversion/branches/fs-progress@WCDB', or perhaps give it
> a symbolic name (and make 'update' change what the symbolic name points
> to).

I've found that git has symbolic names for repositories. Kinda handy
to refer to "myrepos" vs "upstream", rather than remembering the URLs.

Cheers,
-g

Re: Thoughts about issue #3625 (shelving)

[Greg Stein]

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 "stash" feature than git branches.  In
> fact, I was thinking of jumping in and asking why this was being called
> something gratuitously different.

Mercurial calls it shelving. (personally, I tend to refer to 'git
stash' rather than 'hg shelve' given the former's increased
mindshare.. but this thread started with the 'shelve' term)

I expected us to alias 'shelve' and 'stash' to the same operation,
much like we have both 'svn blame' and 'svn praise'.

Cheers,
-g

Re: Thoughts about issue #3625 (shelving)

[Daniel Shahaf]

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 mixed-revisioness etc. Just rewind everything
> >> back to where it was and let a subsequent update sort out the conflicts.
> >> That would already be a big improvement over the diff/patch approach.
> 
> To do this, we'd also want to move op_depth==0 over to the
> SHELF_NODES. Probably a good idea to just copy all of it, rather than
> piecemeal like I suggested, as I suspect that we'd eventually find a
> reason to have BASE present.
> 

Forward-porting of patches?  i.e., locally maintaining a patch on top of
upstream source?  And then when you port the patch it might be nice to
do a 3-way merge (old BASE, new BASE, (old BASE)+patch -> (new BASE)+patch).

> > If we do this, it would be nice if 'restore the former state' could be
> > done offline --- e.g., by retaining the relevant pristines as long as
> > the shelf exists.
> 
> Absolutely. There shouldn't be *any* reason to contact the server. All
> the pristines would be held via SHELF_NODES and SHELF_ACTUAL.
> 

Thought so, just calling out the functional aspect (offline unshelving)
as opposed to the implementation one (this and that tables).

> > (Now, if the working copy is at state S and someone asks to return to
> > a previously-shelved state, what do we do with S?  Do we discard it, or
> > do we first save it somewhere?  And if we save it... do we save it as
> > a new shelf?)
> 
> I *do* envision multiple shelves, and that makes it (imo) even more
> important to look at "unshelve" as merging changes onto the current
> state.
> 
> Regarding current state S... I think "unshelve" should NOT be allowed
> if local mods exist. Thus, we never need to worry about S. The user
> can always explicitly shelve that, return to a no-mods state, and then
> unshelve state-R.
> 
> And yes, we can have an --ignore-local-mods switch to unshelve even
> when local mods exist.
> 

No one said that there are local mods in S; it might be a state with
various mixed-revisions and switched trees, but no local mods.  The
problems that these two introduce might be similar to the problem that
'plain' local mods (text/prop edits) introduce, though?

> 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.
> 
> 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.
> 
> Cheers,
> -g

Re: Thoughts about issue #3625 (shelving)

[Daniel Shahaf]

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

Why do you have separate NODES and SHELF_NODES tables then?  I'd
intuitively expect the NODES table to be replaced by the SHELF_NODES
table, i.e., every working copy state --- including the one immediately
after 'checkout' --- becomes a shelf.  (Though perhaps the first shelf
is 'special' in one or more to-be-determined ways.)

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

Usually want to hack on them concurrently --- i.e., to create a backport
branch and 'make check' it while at the same time adding it to STATUS
and looking at wc-queries.sql on trunk for someone on IRC.  Having
multiple shelves within a single working copy isn't good enough for
such use.

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-progress that you have in .svn'.
('svn switch ^/subversion/branches/fs-progress@WCDB', or perhaps give it
a symbolic name (and make 'update' change what the symbolic name points
to).