You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Olof <ol...@baah.se> on 2016/06/11 17:48:01 UTC
svn:mergeinfo updated for unchanged files/folders at merge of a
feature branch to trunk - is this desirable?
Hello,
Perhaps someone here can bring some light to this topic.
We use the common technique with a trunk and feature branches. A feature
branch is created by branching trunk. The feature branch is continually
kept up-to-date with trunk by merging changes from trunk to feature branch
(rebase). When development in the feature branch is finished the content is
merged back to trunk.
When the feature branch is merged back to trunk all changes to the feature
branch, including those created by rebase, is recorded in svn:mergeinfo
property of the affected file/folder in trunk. One consequence of this is
that files and folders which have not been updated in the feature branch
(except by rebase) is marked as changed (property only) in trunk when the
feature branch is merged back to trunk.
The trunk log shows that these folders/files where changed when the feature
branch was merged back to trunk despite that no folder/file content has
been changed in the feature branch relative to trunk. This is quite
confusing for our users because TortoiseSVN shows that a lot of
folders/files they haven't changed have been updated in the merge. In
addition a lot of unchanged files will be shown as updated at next SVN
update command. Why is this necessary? Is it a desirable behavior?
Shouldn't SVN be able to figure our what's actually changed in the feature
branch relative to trunk and record only this mergeinfo?
Olof Wolgast
Re: svn:mergeinfo updated for unchanged files/folders at merge of a
feature branch to trunk - is this desirable?
Posted by Stefan Hett <st...@egosoft.com>.
On 6/12/2016 12:39 PM, Branko \u010cibej wrote:
> On 12.06.2016 10:06, Yves Martin wrote:
>> On Sun, 2016-06-12 at 02:11 +0200, Branko \u010cibej wrote:
>>
>>>> It's not a result of merge of individual folders. I find the pattern
>>>> in the log for commits I've done and I have most definitely not gone
>>>> out of my way to explicitly merge several subfolders one-by-one.
>>> As I said, once the subtree mergeinfo is in the repository, it will be
>>> updated in /every/ merge.
>>>
>>>> All users use TortoiseSVN. You think it's related to the client?
>>>> Should I ask the Tortoise community instead?
>>> We'de really need a more detailed what's actually happening. I'm afraid
>>> that for now we're only guessing based on your description of the logs;
>>> that's far from enough.
>>>
>>> Personally, the few times I've used TortoiseSVN for merging, I didn't
>>> notice it behaving in any way differently from the command-line client.
>> Hello,
>>
>> The main issue is that merge operation will add a "svn:mergeinfo" at the
>> current working directory where operation is applied.
> Yes, as I noted above; and this is necessary in order to make 'svn
> merge' work correctly.
>
>> But it is expected to be only on "root" folder aka /trunk or /branches/xxx
> I'd rather say 'desired', not 'expected'. :)
>
>> Two ways to avoid that: guidelines to developers when merging (often
>> fails) and precommit hook to prevent addition of svn:mergeinfo property
>> to "non-root" folders.
>>
>> To cleanup an existing working-copy, I have designed a Perl script that
>> checks if a svn:mergeinfo may be "moved" up to "root" folder:
>> https://github.com/ymartin59/svn-clean-mergeinfo
> Let me point you at:
>
> https://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/svn-mergeinfo-normalizer
>
> This is not part of any Subversion release yet, but it's fairly complete
> feature-wise and could surely use a lot of testing in real-world
> environments.
And in case you wanna give it a quick try: It's included in MaxSVN's
trunk dev builds:
http://www.luke1410.de/typo3/index.php?id=97
(runs on Win Vista+ only - 64-bit)
As Brane stated, be careful and double check the results before
committing any changes.
--
Regards,
Stefan Hett
Re: svn:mergeinfo updated for unchanged files/folders at merge of a
feature branch to trunk - is this desirable?
Posted by Branko Čibej <br...@apache.org>.
On 12.06.2016 10:06, Yves Martin wrote:
> On Sun, 2016-06-12 at 02:11 +0200, Branko \u010cibej wrote:
>
>>> It's not a result of merge of individual folders. I find the pattern
>>> in the log for commits I've done and I have most definitely not gone
>>> out of my way to explicitly merge several subfolders one-by-one.
>> As I said, once the subtree mergeinfo is in the repository, it will be
>> updated in /every/ merge.
>>
>>> All users use TortoiseSVN. You think it's related to the client?
>>> Should I ask the Tortoise community instead?
>> We'de really need a more detailed what's actually happening. I'm afraid
>> that for now we're only guessing based on your description of the logs;
>> that's far from enough.
>>
>> Personally, the few times I've used TortoiseSVN for merging, I didn't
>> notice it behaving in any way differently from the command-line client.
> Hello,
>
> The main issue is that merge operation will add a "svn:mergeinfo" at the
> current working directory where operation is applied.
Yes, as I noted above; and this is necessary in order to make 'svn
merge' work correctly.
> But it is expected to be only on "root" folder aka /trunk or /branches/xxx
I'd rather say 'desired', not 'expected'. :)
> Two ways to avoid that: guidelines to developers when merging (often
> fails) and precommit hook to prevent addition of svn:mergeinfo property
> to "non-root" folders.
>
> To cleanup an existing working-copy, I have designed a Perl script that
> checks if a svn:mergeinfo may be "moved" up to "root" folder:
> https://github.com/ymartin59/svn-clean-mergeinfo
Let me point you at:
https://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/svn-mergeinfo-normalizer
This is not part of any Subversion release yet, but it's fairly complete
feature-wise and could surely use a lot of testing in real-world
environments.
-- Brane
Re: svn:mergeinfo updated for unchanged files/folders at merge of a
feature branch to trunk - is this desirable?
Posted by Yves Martin <ym...@gmail.com>.
On Sun, 2016-06-12 at 02:11 +0200, Branko \u010cibej wrote:
> > It's not a result of merge of individual folders. I find the pattern
> > in the log for commits I've done and I have most definitely not gone
> > out of my way to explicitly merge several subfolders one-by-one.
>
> As I said, once the subtree mergeinfo is in the repository, it will be
> updated in /every/ merge.
>
> > All users use TortoiseSVN. You think it's related to the client?
> > Should I ask the Tortoise community instead?
>
> We'de really need a more detailed what's actually happening. I'm afraid
> that for now we're only guessing based on your description of the logs;
> that's far from enough.
>
> Personally, the few times I've used TortoiseSVN for merging, I didn't
> notice it behaving in any way differently from the command-line client.
Hello,
The main issue is that merge operation will add a "svn:mergeinfo" at the
current working directory where operation is applied. But it is expected
to be only on "root" folder aka /trunk or /branches/xxx
Two ways to avoid that: guidelines to developers when merging (often
fails) and precommit hook to prevent addition of svn:mergeinfo property
to "non-root" folders.
To cleanup an existing working-copy, I have designed a Perl script that
checks if a svn:mergeinfo may be "moved" up to "root" folder:
https://github.com/ymartin59/svn-clean-mergeinfo
It is not "perfect" (yet... do not hesitate to report issues with test
cases) but it helps a lot to reduce svn:mergeinfo sets. Then a quick
human check is required to finalize: remove remaning properties and
commit the result.
Hope this helps
--
Yves Martin
Re: svn:mergeinfo updated for unchanged files/folders at merge of a
feature branch to trunk - is this desirable?
Posted by Branko Čibej <br...@apache.org>.
On 11.06.2016 22:03, Olof wrote:
>
>
> 2016-06-11 21:53 GMT+02:00 Branko \u010cibej <brane@apache.org
> <ma...@apache.org>>:
>
> On 11.06.2016 21:39, Olof wrote:
> >
> >
> > 2016-06-11 20:03 GMT+02:00 Branko \u010cibej <brane@apache.org
> <ma...@apache.org>
> > <mailto:brane@apache.org <ma...@apache.org>>>:
> >
> > On 11.06.2016 19:48, Olof wrote:
> > > Hello,
> > >
> > > Perhaps someone here can bring some light to this topic.
> > >
> > > We use the common technique with a trunk and feature
> branches. A
> > > feature branch is created by branching trunk. The feature
> branch is
> > > continually kept up-to-date with trunk by merging changes
> from trunk
> > > to feature branch (rebase). When development in the feature
> > branch is
> > > finished the content is merged back to trunk.
> > >
> > > When the feature branch is merged back to trunk all
> changes to the
> > > feature branch, including those created by rebase, is
> recorded in
> > > svn:mergeinfo property of the affected file/folder in
> trunk. One
> > > consequence of this is that files and folders which have
> not been
> > > updated in the feature branch (except by rebase) is marked as
> > changed
> > > (property only) in trunk when the feature branch is merged
> back
> > to trunk.
> > >
> > > The trunk log shows that these folders/files where changed
> when the
> > > feature branch was merged back to trunk despite that no
> folder/file
> > > content has been changed in the feature branch relative to
> > trunk. This
> > > is quite confusing for our users because TortoiseSVN shows
> that
> > a lot
> > > of folders/files they haven't changed have been updated in the
> > merge.
> > > In addition a lot of unchanged files will be shown as
> updated at
> > next
> > > SVN update command. Why is this necessary? Is it a desirable
> > behavior?
> > > Shouldn't SVN be able to figure our what's actually
> changed in the
> > > feature branch relative to trunk and record only this
> mergeinfo?
> >
> > The real question is, where do all that mergeinfo properties
> come
> > from.
> >
> > In typical usage, you'd have an svn:mergeinfo property on
> the root of
> > each branch (including trunk). If mergeinfo properties are
> defined
> > beneath the root, the most likely reason is that someone
> merged a
> > subtree of the branch instead of the whole branch (hence, we
> call this
> > subtree mergeinfo). During a merge, all subtree mergeinfo
> must be
> > updated to reflect the merge results, regardless of whether
> there were
> > any changes in the subtree.
> >
> > I'm also a bit confused about your wording (re:
> "folders/files"):
> > do you
> > actually have mergeinfo on files?
> >
> > -- Brane
> >
> >
> > Now I had a close look at my trunk log. For some commits only files
> > are changed, but there are also many commits for which mergeinfo is
> > added to subfolders despite commit on top level. For example the log
> > might look like
> >
> > a/b/c.txt - modified
> > a/b - modified, mergeinfo only
> > a/d/e.txt - modified
> > a/d - modified, mergeinfo only
> > a - modified, mergeinfo only
> >
> > Since both subfolders of a has been committed I conclude that
> folder a
> > must have been committed in one single commit. The added
> mergeinfo in
> > a, a/b and a/d is essentially identical, folder change only. This
> > doesn't occur for all commits, only some. I cannot see a pattern for
> > which ones. Ideas?
>
> In fact the root of the commit is irrelevant. What's relevant is the
> root of the merge; 'svn merge' creates or updates the svn:mergeinfo
> property, but does not commit it.
>
> An explanation for your example could be that someone merged the two
> text files individually, then committed from the root of the branch,
> like this:
>
> $ cd a/b
> $ svn merge ^/a/b/c.txt c.txt
> $ cd ../d
> $ svn merge ^/a/d/e.txt e.txt
> $ cd ../..
> $ svn commit
>
>
> A subsequent merge at the root of the branch would update the subtree
> mergeinfo on a/b and a/d as well as the root mergeinfo, and it's quite
> reasonable that the mergeinfo becomes equivalent at all levels.
>
> There are valid reasons for doing things like that (or we wouldn't
> support subtree mergeinfo in the first place). Or maybe this is just a
> side effect specific to merge support in some client. I couldn't
> guess.
>
> > No, I don't have mergeinfo on files, my mistake.
>
> That's good. :)
>
> -- Brane
>
>
> It's not a result of merge of individual folders. I find the pattern
> in the log for commits I've done and I have most definitely not gone
> out of my way to explicitly merge several subfolders one-by-one.
As I said, once the subtree mergeinfo is in the repository, it will be
updated in /every/ merge.
> All users use TortoiseSVN. You think it's related to the client?
> Should I ask the Tortoise community instead?
We'de really need a more detailed what's actually happening. I'm afraid
that for now we're only guessing based on your description of the logs;
that's far from enough.
Personally, the few times I've used TortoiseSVN for merging, I didn't
notice it behaving in any way differently from the command-line client.
-- Brane
Re: svn:mergeinfo updated for unchanged files/folders at merge of a
feature branch to trunk - is this desirable?
Posted by Olof <ol...@baah.se>.
2016-06-11 21:53 GMT+02:00 Branko Čibej <br...@apache.org>:
> On 11.06.2016 21:39, Olof wrote:
> >
> >
> > 2016-06-11 20:03 GMT+02:00 Branko Čibej <brane@apache.org
> > <ma...@apache.org>>:
> >
> > On 11.06.2016 19:48, Olof wrote:
> > > Hello,
> > >
> > > Perhaps someone here can bring some light to this topic.
> > >
> > > We use the common technique with a trunk and feature branches. A
> > > feature branch is created by branching trunk. The feature branch is
> > > continually kept up-to-date with trunk by merging changes from
> trunk
> > > to feature branch (rebase). When development in the feature
> > branch is
> > > finished the content is merged back to trunk.
> > >
> > > When the feature branch is merged back to trunk all changes to the
> > > feature branch, including those created by rebase, is recorded in
> > > svn:mergeinfo property of the affected file/folder in trunk. One
> > > consequence of this is that files and folders which have not been
> > > updated in the feature branch (except by rebase) is marked as
> > changed
> > > (property only) in trunk when the feature branch is merged back
> > to trunk.
> > >
> > > The trunk log shows that these folders/files where changed when the
> > > feature branch was merged back to trunk despite that no folder/file
> > > content has been changed in the feature branch relative to
> > trunk. This
> > > is quite confusing for our users because TortoiseSVN shows that
> > a lot
> > > of folders/files they haven't changed have been updated in the
> > merge.
> > > In addition a lot of unchanged files will be shown as updated at
> > next
> > > SVN update command. Why is this necessary? Is it a desirable
> > behavior?
> > > Shouldn't SVN be able to figure our what's actually changed in the
> > > feature branch relative to trunk and record only this mergeinfo?
> >
> > The real question is, where do all that mergeinfo properties come
> > from.
> >
> > In typical usage, you'd have an svn:mergeinfo property on the root of
> > each branch (including trunk). If mergeinfo properties are defined
> > beneath the root, the most likely reason is that someone merged a
> > subtree of the branch instead of the whole branch (hence, we call
> this
> > subtree mergeinfo). During a merge, all subtree mergeinfo must be
> > updated to reflect the merge results, regardless of whether there
> were
> > any changes in the subtree.
> >
> > I'm also a bit confused about your wording (re: "folders/files"):
> > do you
> > actually have mergeinfo on files?
> >
> > -- Brane
> >
> >
> > Now I had a close look at my trunk log. For some commits only files
> > are changed, but there are also many commits for which mergeinfo is
> > added to subfolders despite commit on top level. For example the log
> > might look like
> >
> > a/b/c.txt - modified
> > a/b - modified, mergeinfo only
> > a/d/e.txt - modified
> > a/d - modified, mergeinfo only
> > a - modified, mergeinfo only
> >
> > Since both subfolders of a has been committed I conclude that folder a
> > must have been committed in one single commit. The added mergeinfo in
> > a, a/b and a/d is essentially identical, folder change only. This
> > doesn't occur for all commits, only some. I cannot see a pattern for
> > which ones. Ideas?
>
> In fact the root of the commit is irrelevant. What's relevant is the
> root of the merge; 'svn merge' creates or updates the svn:mergeinfo
> property, but does not commit it.
>
> An explanation for your example could be that someone merged the two
> text files individually, then committed from the root of the branch,
> like this:
>
> $ cd a/b
> $ svn merge ^/a/b/c.txt c.txt
> $ cd ../d
> $ svn merge ^/a/d/e.txt e.txt
> $ cd ../..
> $ svn commit
>
>
> A subsequent merge at the root of the branch would update the subtree
> mergeinfo on a/b and a/d as well as the root mergeinfo, and it's quite
> reasonable that the mergeinfo becomes equivalent at all levels.
>
> There are valid reasons for doing things like that (or we wouldn't
> support subtree mergeinfo in the first place). Or maybe this is just a
> side effect specific to merge support in some client. I couldn't guess.
>
> > No, I don't have mergeinfo on files, my mistake.
>
> That's good. :)
>
> -- Brane
>
It's not a result of merge of individual folders. I find the pattern in the
log for commits I've done and I have most definitely not gone out of my way
to explicitly merge several subfolders one-by-one. All users use
TortoiseSVN. You think it's related to the client? Should I ask the
Tortoise community instead?
// Olof
Re: svn:mergeinfo updated for unchanged files/folders at merge of a
feature branch to trunk - is this desirable?
Posted by Branko Čibej <br...@apache.org>.
On 11.06.2016 21:39, Olof wrote:
>
>
> 2016-06-11 20:03 GMT+02:00 Branko \u010cibej <brane@apache.org
> <ma...@apache.org>>:
>
> On 11.06.2016 19:48, Olof wrote:
> > Hello,
> >
> > Perhaps someone here can bring some light to this topic.
> >
> > We use the common technique with a trunk and feature branches. A
> > feature branch is created by branching trunk. The feature branch is
> > continually kept up-to-date with trunk by merging changes from trunk
> > to feature branch (rebase). When development in the feature
> branch is
> > finished the content is merged back to trunk.
> >
> > When the feature branch is merged back to trunk all changes to the
> > feature branch, including those created by rebase, is recorded in
> > svn:mergeinfo property of the affected file/folder in trunk. One
> > consequence of this is that files and folders which have not been
> > updated in the feature branch (except by rebase) is marked as
> changed
> > (property only) in trunk when the feature branch is merged back
> to trunk.
> >
> > The trunk log shows that these folders/files where changed when the
> > feature branch was merged back to trunk despite that no folder/file
> > content has been changed in the feature branch relative to
> trunk. This
> > is quite confusing for our users because TortoiseSVN shows that
> a lot
> > of folders/files they haven't changed have been updated in the
> merge.
> > In addition a lot of unchanged files will be shown as updated at
> next
> > SVN update command. Why is this necessary? Is it a desirable
> behavior?
> > Shouldn't SVN be able to figure our what's actually changed in the
> > feature branch relative to trunk and record only this mergeinfo?
>
> The real question is, where do all that mergeinfo properties come
> from.
>
> In typical usage, you'd have an svn:mergeinfo property on the root of
> each branch (including trunk). If mergeinfo properties are defined
> beneath the root, the most likely reason is that someone merged a
> subtree of the branch instead of the whole branch (hence, we call this
> subtree mergeinfo). During a merge, all subtree mergeinfo must be
> updated to reflect the merge results, regardless of whether there were
> any changes in the subtree.
>
> I'm also a bit confused about your wording (re: "folders/files"):
> do you
> actually have mergeinfo on files?
>
> -- Brane
>
>
> Now I had a close look at my trunk log. For some commits only files
> are changed, but there are also many commits for which mergeinfo is
> added to subfolders despite commit on top level. For example the log
> might look like
>
> a/b/c.txt - modified
> a/b - modified, mergeinfo only
> a/d/e.txt - modified
> a/d - modified, mergeinfo only
> a - modified, mergeinfo only
>
> Since both subfolders of a has been committed I conclude that folder a
> must have been committed in one single commit. The added mergeinfo in
> a, a/b and a/d is essentially identical, folder change only. This
> doesn't occur for all commits, only some. I cannot see a pattern for
> which ones. Ideas?
In fact the root of the commit is irrelevant. What's relevant is the
root of the merge; 'svn merge' creates or updates the svn:mergeinfo
property, but does not commit it.
An explanation for your example could be that someone merged the two
text files individually, then committed from the root of the branch,
like this:
$ cd a/b
$ svn merge ^/a/b/c.txt c.txt
$ cd ../d
$ svn merge ^/a/d/e.txt e.txt
$ cd ../..
$ svn commit
A subsequent merge at the root of the branch would update the subtree
mergeinfo on a/b and a/d as well as the root mergeinfo, and it's quite
reasonable that the mergeinfo becomes equivalent at all levels.
There are valid reasons for doing things like that (or we wouldn't
support subtree mergeinfo in the first place). Or maybe this is just a
side effect specific to merge support in some client. I couldn't guess.
> No, I don't have mergeinfo on files, my mistake.
That's good. :)
-- Brane
Re: svn:mergeinfo updated for unchanged files/folders at merge of a
feature branch to trunk - is this desirable?
Posted by Olof <ol...@baah.se>.
2016-06-11 20:03 GMT+02:00 Branko Čibej <br...@apache.org>:
> On 11.06.2016 19:48, Olof wrote:
> > Hello,
> >
> > Perhaps someone here can bring some light to this topic.
> >
> > We use the common technique with a trunk and feature branches. A
> > feature branch is created by branching trunk. The feature branch is
> > continually kept up-to-date with trunk by merging changes from trunk
> > to feature branch (rebase). When development in the feature branch is
> > finished the content is merged back to trunk.
> >
> > When the feature branch is merged back to trunk all changes to the
> > feature branch, including those created by rebase, is recorded in
> > svn:mergeinfo property of the affected file/folder in trunk. One
> > consequence of this is that files and folders which have not been
> > updated in the feature branch (except by rebase) is marked as changed
> > (property only) in trunk when the feature branch is merged back to trunk.
> >
> > The trunk log shows that these folders/files where changed when the
> > feature branch was merged back to trunk despite that no folder/file
> > content has been changed in the feature branch relative to trunk. This
> > is quite confusing for our users because TortoiseSVN shows that a lot
> > of folders/files they haven't changed have been updated in the merge.
> > In addition a lot of unchanged files will be shown as updated at next
> > SVN update command. Why is this necessary? Is it a desirable behavior?
> > Shouldn't SVN be able to figure our what's actually changed in the
> > feature branch relative to trunk and record only this mergeinfo?
>
> The real question is, where do all that mergeinfo properties come from.
>
> In typical usage, you'd have an svn:mergeinfo property on the root of
> each branch (including trunk). If mergeinfo properties are defined
> beneath the root, the most likely reason is that someone merged a
> subtree of the branch instead of the whole branch (hence, we call this
> subtree mergeinfo). During a merge, all subtree mergeinfo must be
> updated to reflect the merge results, regardless of whether there were
> any changes in the subtree.
>
> I'm also a bit confused about your wording (re: "folders/files"): do you
> actually have mergeinfo on files?
>
> -- Brane
>
Now I had a close look at my trunk log. For some commits only files are
changed, but there are also many commits for which mergeinfo is added to
subfolders despite commit on top level. For example the log might look like
a/b/c.txt - modified
a/b - modified, mergeinfo only
a/d/e.txt - modified
a/d - modified, mergeinfo only
a - modified, mergeinfo only
Since both subfolders of a has been committed I conclude that folder a must
have been committed in one single commit. The added mergeinfo in a, a/b and
a/d is essentially identical, folder change only. This doesn't occur for
all commits, only some. I cannot see a pattern for which ones. Ideas?
No, I don't have mergeinfo on files, my mistake.
Re: svn:mergeinfo updated for unchanged files/folders at merge of a
feature branch to trunk - is this desirable?
Posted by Branko Čibej <br...@apache.org>.
On 11.06.2016 19:48, Olof wrote:
> Hello,
>
> Perhaps someone here can bring some light to this topic.
>
> We use the common technique with a trunk and feature branches. A
> feature branch is created by branching trunk. The feature branch is
> continually kept up-to-date with trunk by merging changes from trunk
> to feature branch (rebase). When development in the feature branch is
> finished the content is merged back to trunk.
>
> When the feature branch is merged back to trunk all changes to the
> feature branch, including those created by rebase, is recorded in
> svn:mergeinfo property of the affected file/folder in trunk. One
> consequence of this is that files and folders which have not been
> updated in the feature branch (except by rebase) is marked as changed
> (property only) in trunk when the feature branch is merged back to trunk.
>
> The trunk log shows that these folders/files where changed when the
> feature branch was merged back to trunk despite that no folder/file
> content has been changed in the feature branch relative to trunk. This
> is quite confusing for our users because TortoiseSVN shows that a lot
> of folders/files they haven't changed have been updated in the merge.
> In addition a lot of unchanged files will be shown as updated at next
> SVN update command. Why is this necessary? Is it a desirable behavior?
> Shouldn't SVN be able to figure our what's actually changed in the
> feature branch relative to trunk and record only this mergeinfo?
The real question is, where do all that mergeinfo properties come from.
In typical usage, you'd have an svn:mergeinfo property on the root of
each branch (including trunk). If mergeinfo properties are defined
beneath the root, the most likely reason is that someone merged a
subtree of the branch instead of the whole branch (hence, we call this
subtree mergeinfo). During a merge, all subtree mergeinfo must be
updated to reflect the merge results, regardless of whether there were
any changes in the subtree.
I'm also a bit confused about your wording (re: "folders/files"): do you
actually have mergeinfo on files?
-- Brane