You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Neels J Hofmeyr <ne...@elego.de> on 2011/08/29 17:21:32 UTC
[PATCH] don't recursively-commit pegged file externals
Anyone up for discussing the two '###'-comments in this patch's log message?
I think this patch is necessary, but feel free to discuss it to smithereens.
I'd say +1 for both '###'-comments, for consistency with dir externals.
Re: Recurse into same-repos externals at commit time.
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
C. Michael Pilato wrote on Mon, Aug 29, 2011 at 14:46:40 -0400:
> On 08/29/2011 02:23 PM, Daniel Shahaf wrote:
> > C. Michael Pilato wrote on Mon, Aug 29, 2011 at 12:23:34 -0400:
> >> On 08/29/2011 12:15 PM, Neels J Hofmeyr wrote:
> >>> If user wants to commit to a *pegged* external, user should just use a
> >>> different, non-externals-ized checkout.
> >>
> >> AFAIK, we don't have the means to detect and prevent this action.
> >
> > Did you mean, "no means that don't involve recursing to the parent of
> > the wcroot of the commit target"?
>
> That's not sufficient. We'd have to keep recursing up to the root of the
> volume to get a definitive answer because the definition of an external
> working copy could live in *any* parent directory thereof. I demonstrate
> this simply with the following:
>
> sne-wc-top (an empty wc)
> unversioned
> sne-wc-nested (a different empty wc from svn-wc-top)
> unversioned
> sne-wc-ext (a third, different empty wc, which is an
> external not of its parent, or even of the
> nearest versioned ancestor, or even of any
> item within the nearest versioned wc, but
> of a wc even farther up the tree.)
If you have enough levels of this madness then
- You could have a working copy directory in which every file comes from
a different working copy.
- You could checkout a repository that has one revision and contains no
files or directories into the root directory and get files created at
arbitrary locations in your filesystem.
- You could nest N working copies and have all N try and create the same
dirent_abspath in the host file system [1].
So, I have two responses:
- Don't do that.
- If you do it anyway, make 'svn status' and 'svn info' recognize those
'distant children'.
[1] Neels, when I mentioned shadowing on IRC earlier I referred to
shadowing within one repository, not to cmpilato's overlapping working
copies' example here.)
Re: Recurse into same-repos externals at commit time.
Posted by Neels J Hofmeyr <ne...@elego.de>.
On 08/29/2011 08:46 PM, C. Michael Pilato wrote:
> sne-wc-top (an empty wc)
> unversioned
> sne-wc-nested (a different empty wc from svn-wc-top)
> unversioned
> sne-wc-ext (a third, different empty wc, which is an
> external not of its parent, or even of the
> nearest versioned ancestor, or even of any
> item within the nearest versioned wc, but
> of a wc even farther up the tree.)
Hmmm, actually I was wrong assuming that there is no entire separate
checkout in a subdir anymore. Only now do I grasp the vastness of externals
land. * bows to CMike & Bert
I see now that cleanly omitting direct externals targets, no matter where
they are, is difficult. I won't attempt to skip explicit targets ATM, not
before a whole lot more thinking; thanks Mike.
I tested, and this nested stuff looks pretty much like uncharted subversion
land. This could be "The Bermuda Delta", where magnetic fields hide subtrees
from your status and make clients crash, never to be seen again...
There likely are many more problems ATM than I found below. So I guess we
should probably *design* what it should behave like.
As if that was something new.
I guess ideally we want to reserve the term "externals" for those items that
have an explicit svn:externals definition. Don't include other WC-roots with
the --include-externals option. Like this:
Commit:
(1) by default stop recursing at the slightest WC ripples
(2) but if --include-externals is passed, also jump into all the externals
items known to *this* WC by svn:externals definitions
(3) Even with --include-externals, do not step into switched or separately
checked-out WCs that are lacking a matching svn:externals definition in
*this* WC.
(4) '*this* WC' is always closely tied to the target: when an explicit
target is (inside) a dir-external from a 'parent WC', we regard
inside-the-dir-external as '*this* WC', not the 'parent WC'.
(5) Externals coming in from 'parent WCs' are ignored (ideally as unversioned).
And the next mad thing would be --include-nests (or something) that would
recurse through all of unversioned, external'd, switched, separate WCs and
nestings thereof and commit all to their respective proper places.
(And would have to step through all ancestors to find which of its
unversioned files are in fact externals from 'parent WCs')
If interested, here's what I tested with 1.7.x:
legend:
UNV: unversioned dir
V1, V2, ...: versioned dir
xV1, xV2, ...: dir external of V1, V2, ...
xfile: file external
When there's a dir external V1/UNV/V2/UNV/xV3 (svn:externals on V1),
curiously, status shows:
[[[
+ svn status V1
X V1/UNV
]]]
Even though the external is way deeper, it appears UNV is the external. Is
that intentional?
I see that this could make sense when there are numerous externals inside
UNV, but maybe we should use some longest_common_ancestor stuff instead, if
we really wanna do that.
Then I tested this with file externals :)
[[[
Fetching external item into 'V1/UNV/V2/xfile2':
svn: warning: W155022: Cannot insert a file external defined on '/tmp/wc/V1'
into the working copy '/tmp/wc/V1/UNV/V2'.
]]]
But setting a file external inside an unversioned dir works. It also causes
a status that shows the unversioned ancestor as 'X', not the file external
itself.
[[[
$ svn up
...
Fetching external item into 'V1/UNV/V2/UNV/xV3':
A V1/UNV/V2/UNV/xV3/v
Updated external to revision 4.
Fetching external item into 'V1/UNV2/xfile':
A V1/UNV2/xfile
Updated external to revision 4.
# make local textmods in both externals
$ echo mod >> V1/UNV/V2/UNV/xV3/v
$ echo mod >> V1/UNV2/xfile
$ svn status V1
X V1/UNV
X V1/UNV2
Performing status on external item at 'V1/UNV/V2/UNV/xV3':
M /tmp/nested_wc_unver_wc.7QJ/wc/V1/UNV/V2/UNV/xV3/v
# file external V1/UNV2/xfile is omitted from this status,
# though the dir external got some special status-attention.
# A direct status on the file external also fails:
$ svn status V1/UNV2/xfile
svn: E155010: The node '/tmp/nested_wc_unver_wc.7QJ/wc/V1/UNV2' was not found.
# svn info is successful on V1/UNV2/xfile, though.
$ svn info V1/UNV2/xfile
Path: V1/UNV2/xfile
Name: xfile
Working Copy Root Path: /tmp/nested_wc_unver_wc.0lP/wc
URL: file:///tmp/nested_wc_unver_wc.0lP/repos/V3/v
...
# commit doesn't bother about either.
# The file external is even rejected as direct commit target:
$ svn ci -mm V1/UNV2/xfile
svn: E155010: Commit failed (details follow):
svn: E155010: The node '/tmp/nested_wc_unver_wc.dDv/wc/V1/UNV2' was not found.
]]]
~Neels
Re: Recurse into same-repos externals at commit time.
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 08/29/2011 02:23 PM, Daniel Shahaf wrote:
> C. Michael Pilato wrote on Mon, Aug 29, 2011 at 12:23:34 -0400:
>> On 08/29/2011 12:15 PM, Neels J Hofmeyr wrote:
>>> If user wants to commit to a *pegged* external, user should just use a
>>> different, non-externals-ized checkout.
>>
>> AFAIK, we don't have the means to detect and prevent this action.
>
> Did you mean, "no means that don't involve recursing to the parent of
> the wcroot of the commit target"?
That's not sufficient. We'd have to keep recursing up to the root of the
volume to get a definitive answer because the definition of an external
working copy could live in *any* parent directory thereof. I demonstrate
this simply with the following:
{{{
#!/bin/bash
# Cleanup previous runs and make a repository with some top-level dirs.
rm -rf sne-*
svnadmin create sne-repos
svn mkdir -m "Some dirs" file://`pwd`/sne-repos/main \
file://`pwd`/sne-repos/nested \
file://`pwd`/sne-repos/ext
# Checkout main.
svn co file://`pwd`/sne-repos/main \
sne-wc-top
# Checkout nested inside an unversion subdir of the first checkout.
mkdir sne-wc-top/unversioned
svn co file://`pwd`/sne-repos/nested \
sne-wc-top/unversioned/sne-wc-nested
# Now set an external in main that pulls ext all the way down into nested.
svn pset svn:externals \
'^/ext unversioned/sne-wc-nested/unversioned/sne-wc-ext' \
sne-wc-top
svn up sne-wc-top
}}}
After this script is run, you have:
sne-wc-top (an empty wc)
unversioned
sne-wc-nested (a different empty wc from svn-wc-top)
unversioned
sne-wc-ext (a third, different empty wc, which is an
external not of its parent, or even of the
nearest versioned ancestor, or even of any
item within the nearest versioned wc, but
of a wc even farther up the tree.)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Recurse into same-repos externals at commit time.
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
C. Michael Pilato wrote on Mon, Aug 29, 2011 at 12:23:34 -0400:
> On 08/29/2011 12:15 PM, Neels J Hofmeyr wrote:
> > If user wants to commit to a *pegged* external, user should just use a
> > different, non-externals-ized checkout.
>
> AFAIK, we don't have the means to detect and prevent this action.
Did you mean, "no means that don't involve recursing to the parent of
the wcroot of the commit target"?
RE: Recurse into same-repos externals at commit time.
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Neels J Hofmeyr [mailto:neels@elego.de]
> Sent: maandag 29 augustus 2011 20:47
> To: dev@subversion.apache.org
> Subject: Re: Recurse into same-repos externals at commit time.
>
> On 08/29/2011 06:23 PM, C. Michael Pilato wrote:
> > On 08/29/2011 12:15 PM, Neels J Hofmeyr wrote:
> >> - when an external is passed as explicit target, still require
> >> --include-externals?
> >
> > No. Because we've recommended in the issue I referenced exactly this
> > behavior as a workaround for this missing feature.
> >> I'd say yes (thinking of 'svn commit *')
> > Is 'svn commit *' really something that people do? I mean, commit is
> > recursive by nature, so I'd suspect that 'svn commit' is the more common
> > invocation.
> [...]
> > When explicitly named, though, we've
> > always allowed such commits because from the perspective of such an
> > operation, we're not looking at an external, just a working copy. (An
> > external's external-ness is defined outside it's own scope, right?)
>
> This is a good point, but IMHO ceases to be one with release 1.7. There no
> longer is a detached administrative .svn/ inside an external dir. It really
> is an external inside a "real" WC, always detectable, always overlayed.
There still is a .svn in a directory external in 1.7.
Bert
RE: Recurse into same-repos externals at commit time.
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato@collab.net]
> Sent: maandag 29 augustus 2011 21:55
> To: Neels J Hofmeyr
> Cc: dev@subversion.apache.org
> Subject: Re: Recurse into same-repos externals at commit time.
>
> On 08/29/2011 02:47 PM, Neels J Hofmeyr wrote:
> > On 08/29/2011 06:23 PM, C. Michael Pilato wrote:
> >> On 08/29/2011 12:15 PM, Neels J Hofmeyr wrote:
> >>> - when an external is passed as explicit target, still require
> >>> --include-externals?
> >>
> >> No. Because we've recommended in the issue I referenced exactly this
> >> behavior as a workaround for this missing feature.
> >>> I'd say yes (thinking of 'svn commit *')
> >> Is 'svn commit *' really something that people do? I mean, commit is
> >> recursive by nature, so I'd suspect that 'svn commit' is the more common
> >> invocation.
> > [...]
> >> When explicitly named, though, we've
> >> always allowed such commits because from the perspective of such an
> >> operation, we're not looking at an external, just a working copy. (An
> >> external's external-ness is defined outside it's own scope, right?)
> >
> > This is a good point, but IMHO ceases to be one with release 1.7. There no
> > longer is a detached administrative .svn/ inside an external dir. It really
> > is an external inside a "real" WC, always detectable, always overlayed.
>
> Really? I'm not so sure. Using the example I brought up elsethread:
>
> $ find sne-wc-top -name .svn
> sne-wc-top/.svn
> sne-wc-top/unversioned/sne-wc-nested/.svn
> sne-wc-top/unversioned/sne-wc-nested/unversioned/sne-wc-ext/.svn
>
> And I recall arguing against the merging of external working copies into the
> primary one, too. An externals is an *external*, not an internal. :-)
> Sadly, we were forced to do so with file externals. (And maybe that's the
> use-case you were thinking of when you responded above?)
Even with separate working copies we could still move the data to a central wc.db and pristine area. All it would take is a marker in the separate working copy to make us find the store in a parent directory.
(This information could just be stored in the already written entries file)
Bert
Re: Recurse into same-repos externals at commit time.
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 08/29/2011 02:47 PM, Neels J Hofmeyr wrote:
> On 08/29/2011 06:23 PM, C. Michael Pilato wrote:
>> On 08/29/2011 12:15 PM, Neels J Hofmeyr wrote:
>>> - when an external is passed as explicit target, still require
>>> --include-externals?
>>
>> No. Because we've recommended in the issue I referenced exactly this
>> behavior as a workaround for this missing feature.
>>> I'd say yes (thinking of 'svn commit *')
>> Is 'svn commit *' really something that people do? I mean, commit is
>> recursive by nature, so I'd suspect that 'svn commit' is the more common
>> invocation.
> [...]
>> When explicitly named, though, we've
>> always allowed such commits because from the perspective of such an
>> operation, we're not looking at an external, just a working copy. (An
>> external's external-ness is defined outside it's own scope, right?)
>
> This is a good point, but IMHO ceases to be one with release 1.7. There no
> longer is a detached administrative .svn/ inside an external dir. It really
> is an external inside a "real" WC, always detectable, always overlayed.
Really? I'm not so sure. Using the example I brought up elsethread:
$ find sne-wc-top -name .svn
sne-wc-top/.svn
sne-wc-top/unversioned/sne-wc-nested/.svn
sne-wc-top/unversioned/sne-wc-nested/unversioned/sne-wc-ext/.svn
And I recall arguing against the merging of external working copies into the
primary one, too. An externals is an *external*, not an internal. :-)
Sadly, we were forced to do so with file externals. (And maybe that's the
use-case you were thinking of when you responded above?)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Recurse into same-repos externals at commit time.
Posted by Neels J Hofmeyr <ne...@elego.de>.
On 08/29/2011 06:23 PM, C. Michael Pilato wrote:
> On 08/29/2011 12:15 PM, Neels J Hofmeyr wrote:
>> - when an external is passed as explicit target, still require
>> --include-externals?
>
> No. Because we've recommended in the issue I referenced exactly this
> behavior as a workaround for this missing feature.
>> I'd say yes (thinking of 'svn commit *')
> Is 'svn commit *' really something that people do? I mean, commit is
> recursive by nature, so I'd suspect that 'svn commit' is the more common
> invocation.
[...]
> When explicitly named, though, we've
> always allowed such commits because from the perspective of such an
> operation, we're not looking at an external, just a working copy. (An
> external's external-ness is defined outside it's own scope, right?)
This is a good point, but IMHO ceases to be one with release 1.7. There no
longer is a detached administrative .svn/ inside an external dir. It really
is an external inside a "real" WC, always detectable, always overlayed.
Don't you think it's a cleaner UI design if we simply require
--include-externals to commit externals, recursive or not? Sort of protect
the user from doing unintended commits? Of course people usually don't 'svn
commit *', but I could imagine doing 'svn commit sub/dir/*.[hc]' and
forgetting that conf.h is an external in there. Or even "I'm used to
externals being skipped, because I usually use recursive commits and wasn't
aware of that UI detail. Now I've committed nonsense.".
Yeah but I don't think this is such a pressing detail. If you don't think
it's a more betterer UI to always require --include-externals, I'm cool with
that. (Also since my argument goes both ways, as I just noticed.)
If I get my way though, I'll add an error message aborting the commit,
informing about the need for --include-externals.
>> If user wants to commit to a *pegged* external, user should just use a
>> different, non-externals-ized checkout.
> AFAIK, we don't have the means to detect and prevent this action.
But we do :)
See my patch, which uses it.
~Neels
Re: Recurse into same-repos externals at commit time.
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 08/29/2011 12:15 PM, Neels J Hofmeyr wrote:
> On 08/29/2011 05:48 PM, C. Michael Pilato wrote:
>> No sweat. 'svn commit --include-externals' sounds like a fine plan.
>
> +1 and volunteering.
>
> So by default, *all* externals shall be skipped from commit (dir and file
> externals alike).
>
> When --include-externals is passed to 'svn commit', *all* externals are
> recursed into (dir and file externals alike).
>
> However, an external that has a specific peg revision (file and dir
> externals alike) is never recursively included in commit.
>
> Questions remain about passing externals explicitly:
>
> - when an external is passed as explicit target, still require
> --include-externals?
No. Because we've recommended in the issue I referenced exactly this
behavior as a workaround for this missing feature.
> - when a *pegged* external is passed as explicit target (and say even if
> --include-externals is passed), should we *still* refuse to commit it?
>
> I'd say yes (thinking of 'svn commit *') and yes (thinking of avoiding
> inconsistent external state as seen with file externals, and of changes
> snapping back to peg as seen with dir externals).
Is 'svn commit *' really something that people do? I mean, commit is
recursive by nature, so I'd suspect that 'svn commit' is the more common
invocation.
As for the second question, I'm +0 on disallowing commits of pegged
externals when not explicitly named. When explicitly name, though, we've
always allowed such commits because from the perspective of such an
operation, we're not looking at an external, just a working copy. (An
external's external-ness is defined outside it's own scope, right?)
> If user wants to commit to a *pegged* external, user should just use a
> different, non-externals-ized checkout.
AFAIK, we don't have the means to detect and prevent this action.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Recurse into same-repos externals at commit time.
Posted by Neels J Hofmeyr <ne...@elego.de>.
On 08/29/2011 06:15 PM, Neels J Hofmeyr wrote:
> - when a *pegged* external is passed as explicit target (and say even if
> --include-externals is passed), should we *still* refuse to commit it?
>
> I'd say [...] yes (thinking of avoiding
> inconsistent external state as seen with file externals, and of changes
> snapping back to peg as seen with dir externals).
>
> If user wants to commit to a *pegged* external, user should just use a
> different, non-externals-ized checkout.
Noting that this is currently only easy enforce for file externals, as they
can't exist across nested WCs.
To block any item inside a pegged dir external, even if passed as explicit
target, one would have to find out for each and every target whether one of
its ancestors is a pegged dir external. So on every commit target, one would
have to scan all the way to the root dir to see if any parent WC has any
svn:externals definition that is an ancestor of this target. Gah.
So a dir ext'l will remain committable if passed as target, even if it is
pegged. By forbidding this for file ext'ls, we decide for another
inconsistency. I'll just stop the recursion to file-ext'ls then.
Thanks for the review!
<thinking-out-loud>All that would be needed to block pegged dir externals is
e.g. that each WC-root's .svn/ has a record somewhere accessible, which
indicates whether this WC was checked out as an external by another WC, and
if so whether it is revision-pegged. Wouldn't even need to know which
WC-root holds its matching svn:externals definition, but might as well store
that too. --I'm probably forgetting a million other things certain others
already thought of before this proposal, as usual.</thinking-out-loud>
~Neels
Re: Recurse into same-repos externals at commit time.
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Aug 30, 2011 at 8:55 AM, Markus Schaber
<m....@3s-software.com> wrote:
[...]
>> Questions remain about passing externals explicitly:
>>
>> - when an external is passed as explicit target, still require --include-
>> externals?
>
> IMHO: Do not require --include-externals. If I only want to commit a single file which happens to reside inside an external subdirectory, and give that file explicitly, I do not want to say "--include-externals".
+1. It has always worked that way, that you can commit an external
(dir) by specifying it explicitly (how else would you do it
currently). We have some scripts that do exactly that:
$ cd dir-only-containing-externals
$ svn commit * # commits all the external dirs.
--
Johan
AW: Recurse into same-repos externals at commit time.
Posted by Markus Schaber <m....@3s-software.com>.
Hi,
Von: Neels J Hofmeyr [mailto:neels@elego.de]
>
> On 08/29/2011 05:48 PM, C. Michael Pilato wrote:
> > No sweat. 'svn commit --include-externals' sounds like a fine plan.
>
> +1 and volunteering.
Great, thanks!
> So by default, *all* externals shall be skipped from commit (dir and file
> externals alike).
>
> When --include-externals is passed to 'svn commit', *all* externals are
> recursed into (dir and file externals alike).
>
> However, an external that has a specific peg revision (file and dir
> externals alike) is never recursively included in commit.
>
> Questions remain about passing externals explicitly:
>
> - when an external is passed as explicit target, still require --include-
> externals?
IMHO: Do not require --include-externals. If I only want to commit a single file which happens to reside inside an external subdirectory, and give that file explicitly, I do not want to say "--include-externals".
> - when a *pegged* external is passed as explicit target (and say even if -
> -include-externals is passed), should we *still* refuse to commit it?
Here, I say yes. We also do not allow to commit when the working copy is not at head revision.
> I'd say yes (thinking of 'svn commit *') and yes (thinking of avoiding
> inconsistent external state as seen with file externals, and of changes
> snapping back to peg as seen with dir externals).
>
> If user wants to commit to a *pegged* external, user should just use a
> different, non-externals-ized checkout.
Ack.
Best regards
Markus Schaber
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber@3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: Recurse into same-repos externals at commit time.
Posted by Neels J Hofmeyr <ne...@elego.de>.
On 08/29/2011 05:48 PM, C. Michael Pilato wrote:
> No sweat. 'svn commit --include-externals' sounds like a fine plan.
+1 and volunteering.
So by default, *all* externals shall be skipped from commit (dir and file
externals alike).
When --include-externals is passed to 'svn commit', *all* externals are
recursed into (dir and file externals alike).
However, an external that has a specific peg revision (file and dir
externals alike) is never recursively included in commit.
Questions remain about passing externals explicitly:
- when an external is passed as explicit target, still require
--include-externals?
- when a *pegged* external is passed as explicit target (and say even if
--include-externals is passed), should we *still* refuse to commit it?
I'd say yes (thinking of 'svn commit *') and yes (thinking of avoiding
inconsistent external state as seen with file externals, and of changes
snapping back to peg as seen with dir externals).
If user wants to commit to a *pegged* external, user should just use a
different, non-externals-ized checkout.
~Neels
Re: Recurse into same-repos externals at commit time.
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 08/29/2011 11:45 AM, Bert Huijben wrote:
>
>
>> -----Original Message-----
>> From: C. Michael Pilato [mailto:cmpilato@collab.net]
>> Sent: maandag 29 augustus 2011 17:40
>> To: Neels J Hofmeyr
>> Cc: Subversion Development
>> Subject: Recurse into same-repos externals at commit time. (was: [PATCH]
>> don't recursively-commit pegged file externals)
>>
>> On 08/29/2011 11:33 AM, C. Michael Pilato wrote:
>>>> ### It is also debatable if we should also skip *un*pegged file externals
>>>> from recursion, just like we do with dir externals.
>>>
>>> I tend to lobby for treatment of file externals more consistently with
>>> directory externals. But now that our commit crawler can handle multi-WC
>>> commits, we could probably enable commit recursion into directory
>> externals
>>> which are pulled from the same repository as the primary one. (Maybe
>> Bert
>>> has some thoughts about this?)
>>
>> See http://subversion.tigris.org/issues/show_bug.cgi?id=1167 (circa 2003).
>>
>> This would actually be a pretty cool to make happen for 1.8.
>>
>> What might the UI look like? Would we just skip (with a notification) any
>> externals pulled from a foreign repository?
>
> Personally, I don't think we should change the default behavior of not committing the externals with the parent.
>
> I have no problem with adding an optional behavior, but I think the user should somehow choose to add them to the commit or it would surprise users and scripts that don't expect the current behavior to change.
> (That is why I didn't add this part of the feature request)
No sweat. 'svn commit --include-externals' sounds like a fine plan.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
RE: Recurse into same-repos externals at commit time. (was: [PATCH] don't recursively-commit pegged file externals)
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato@collab.net]
> Sent: maandag 29 augustus 2011 17:40
> To: Neels J Hofmeyr
> Cc: Subversion Development
> Subject: Recurse into same-repos externals at commit time. (was: [PATCH]
> don't recursively-commit pegged file externals)
>
> On 08/29/2011 11:33 AM, C. Michael Pilato wrote:
> >> ### It is also debatable if we should also skip *un*pegged file externals
> >> from recursion, just like we do with dir externals.
> >
> > I tend to lobby for treatment of file externals more consistently with
> > directory externals. But now that our commit crawler can handle multi-WC
> > commits, we could probably enable commit recursion into directory
> externals
> > which are pulled from the same repository as the primary one. (Maybe
> Bert
> > has some thoughts about this?)
>
> See http://subversion.tigris.org/issues/show_bug.cgi?id=1167 (circa 2003).
>
> This would actually be a pretty cool to make happen for 1.8.
>
> What might the UI look like? Would we just skip (with a notification) any
> externals pulled from a foreign repository?
Personally, I don't think we should change the default behavior of not committing the externals with the parent.
I have no problem with adding an optional behavior, but I think the user should somehow choose to add them to the commit or it would surprise users and scripts that don't expect the current behavior to change.
(That is why I didn't add this part of the feature request)
Bert
Recurse into same-repos externals at commit time. (was: [PATCH]
don't recursively-commit pegged file externals)
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 08/29/2011 11:33 AM, C. Michael Pilato wrote:
>> ### It is also debatable if we should also skip *un*pegged file externals
>> from recursion, just like we do with dir externals.
>
> I tend to lobby for treatment of file externals more consistently with
> directory externals. But now that our commit crawler can handle multi-WC
> commits, we could probably enable commit recursion into directory externals
> which are pulled from the same repository as the primary one. (Maybe Bert
> has some thoughts about this?)
See http://subversion.tigris.org/issues/show_bug.cgi?id=1167 (circa 2003).
This would actually be a pretty cool to make happen for 1.8.
What might the UI look like? Would we just skip (with a notification) any
externals pulled from a foreign repository?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: [PATCH] don't recursively-commit pegged file externals
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 08/29/2011 11:21 AM, Neels J Hofmeyr wrote:
> Anyone up for discussing the two '###'-comments in this patch's log message?
> I think this patch is necessary, but feel free to discuss it to smithereens.
> I'd say +1 for both '###'-comments, for consistency with dir externals.
[...]
> ### It is debatable if even explicit targets should be skipped.
I agree that it seems weird to allow commits to pegged resources. ("I want
to share this change with the world, but by golly I don't want it myself!")
> ### It is also debatable if we should also skip *un*pegged file externals
> from recursion, just like we do with dir externals.
I tend to lobby for treatment of file externals more consistently with
directory externals. But now that our commit crawler can handle multi-WC
commits, we could probably enable commit recursion into directory externals
which are pulled from the same repository as the primary one. (Maybe Bert
has some thoughts about this?)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand