Ivan Zhakov visualsvn.com> writes:
>
> On 10 March 2014 18:25, Gareth McCaughan
> lightblueoptics.com> wrote:
> > It appears that files checked out using Subversion (1.7 onwards)
> > are marked as not indexable by Windows search. The way in which
> > this happens appears to be as follows:
Woul
rg - sorry if it did.
Anyone know the unsubscribe information for the old list?
Pete Hatton
-
E-mail: p...@monolight.org
Webpage: http://www.monolight.org
-
Quoting "Stein Somers" :
Much easier is to unsubscribe from this spambot by sending an empty
e-mail to users-unsubscr...@subversion.tigris.org
Thanks - that was what I was looking for. Seems to have worked as well.
Pete Hatton
-
E-mail: p...@mon
A known bug?
Thanks,
Pete
Script to reproduce (run as "script.sh /path/to/svn"):
#!/bin/bash
#
# Reproduce an issue in Subversion 1.8.11 where files in a tree
# conflict can have svn:mergeinfo properties added to them during a
# merge.
set -e
SERVER_DIR=server
CLIENT_DIR=client
if [ $
s fully merged? And is this
difference meant to be introduced in 1.8 vs. 1.7? From what I read it
looked like merge semantics weren't intended to change, just some of
the client-side bookkeeping.
Thank you for your time,
--Pete
On Wed, Mar 11, 2015 at 4:25 PM, Bert Huijben wrote:
> I don’t k
I verified that this test also fails the same way on the latest
subversion trunk (1.10.0-dev).
Pass: 1.6.11
Pass: 1.7.17
Fail: 1.8.11
Fail: 1.10.0-dev
Is there a reason not to open a bug report?
Thanks,
--Pete
On Wed, Mar 11, 2015 at 4:54 PM, Pete Harlan wrote:
> Thank you for your re
#x27;t want the subdirectory to have
a detached svn:mergeinfo? I'm using "svn resolve --accept=working
" but that leaves the property in place on the file within path.
Lack of understanding this issue is preventing us from moving past
1.7; any help would be most appreciated.
Thank you,
--
isunderstanding something about the svn:mergeinfo property or
conflict resolution that would explain the need to track dir/file.txt
specially on an ongoing basis?
Thank you for your time.
Pete
On Fri, Mar 13, 2015 at 5:10 PM, Bert Huijben wrote:
>
>
>> -Original Message--
o consider
this a full merge, and not create separate mergeinfo for any interior
nodes.
So I think it would be worth updating "svn resolve" to, by default,
take action to trust the user and mark this as a full resolution. If
the user needs to take an extra step or add a new parameter to get
that effect, would that not feel like a regression compared with 1.7?
Thanks,
Pete
On Sat, Mar 14, 2015 at 4:05 PM, Pete Harlan wrote:
> As you pointed out, my original report erroneously focused on
> svn:mergeinfo appearing, when the real issue is that the new
> svn:mergeinfo doesn't disappear (still) when the user marks the
> conflict resolved. (And I haven
what actually
happened? There can be no mistake about those portions of the merge
being incomplete.
If the svn developers do decide that introducing mergeinfo for [some?
why not all?] conflicted paths is the correct scenario, I would think
that that shouldn't be done until resolve knows how to clean it up.
Pete
ld remove the now-redundant subtree
mergeinfo after #4; I'm not asking for that. But it would be a *bug*
for it to have separate subtree info after #1. That it does, is what
I'm reporting.
In case this helps, here's what's motivating my report. We have a
policy against subtree merges: users are only allowed to commit merges
performed between branch/trunk roots. We enforce that policy by
rejecting commits that add svn:mergeinfo properties to interior nodes.
In my understanding, this is a correct way to enforce the policy,
because subtree merges are what interior svn:mergeinfo properties are
for.
--Pete
bookkeeping, and this doesn't imply lack of a full
root->root merge or other user shenanigans?
I appreciate your time on this.
Thanks,
--Pete
On Tue, Mar 17, 2015 at 8:58 AM, Pete Harlan wrote:
> On Mon, Mar 16, 2015 at 6:08 PM, Branko Čibej wrote:
>>>> In an ideal world, y
On Tue, Mar 24, 2015 at 11:24 AM, Pete Harlan wrote:
> Is it accurate then to say that Subversion may generate explicit
> mergeinfo whenever it decides that there is something useful to record
> about the set of revisions that contributed to a given node, and that
> svn:mergeinfo pr
On Fri, Mar 27, 2015 at 2:27 PM, Johan Corveleyn wrote:
> On Fri, Mar 27, 2015 at 9:01 PM, Pete Harlan wrote:
>> On Tue, Mar 24, 2015 at 11:24 AM, Pete Harlan wrote:
>>> Is it accurate then to say that Subversion may generate explicit
>>> mergeinfo whenever it deci
On Sun, Mar 29, 2015 at 12:00 AM, Daniel Shahaf wrote:
> Pete Harlan wrote on Fri, Mar 27, 2015 at 15:22:16 -0700:
>> On Fri, Mar 27, 2015 at 2:27 PM, Johan Corveleyn wrote:
>> > On Fri, Mar 27, 2015 at 9:01 PM, Pete Harlan wrote:
>> >> On Tue, Mar 24,
On Tue, Mar 31, 2015 at 8:05 AM, Julian Foad wrote:
> Hello.
>
> Firstly I'd like to say thank you, Pete, for bringing up this issue
> and discussing it so clearly.
>
> I had a think about this the other day and chatted with the others on IRC [1].
>
> I picked this
On Thu, Apr 2, 2015 at 11:00 AM, Julian Foad wrote:
> Pete Harlan wrote:
...
>> If you have suggestions for how I could further help this issue along,
>> please let me know. And thanks again very much for your time.
>
> It would help to catalogue the various cases. Maybe st
On Fri, Apr 10, 2015 at 6:40 PM, Branko Čibej wrote:
> On 11.04.2015 02:01, Pete Harlan wrote:
>> On Thu, Apr 2, 2015 at 11:00 AM, Julian Foad
>> wrote:
>>> Pete Harlan wrote:
>> ...
>>>> If you have suggestions for how I could further help this issue a
On Mon, Apr 13, 2015 at 9:31 AM, Julian Foad wrote:
> Pete Harlan wrote:
>> Julian Foad wrote:
> [...]
>>> Another way to help would be to think about how the client could
>>> present the "WC is in a merged state" notion, and how that would
>>> a
On Mon, Apr 13, 2015 at 10:58 AM, Pete Harlan wrote:
>> My scripts are Bash scripts similar to the script I originally posted
>> to this thread. I can share them if you think that would be useful,
>> or I'm happy to rerun them against other versions upon request.
...
Hi,
If you're using Subversion 1.8, you may find this thread relevant:
http://thread.gmane.org/gmane.comp.version-control.subversion.user/118260
It describes specific instances in which Subversion 1.8 (and later)
add mergeinfo to nodes. The mergeinfo there may be safely removed.
--Pet
ake much sense to offer two different resolve options with exactly the
> same result.
Perhaps a user or script wants to resolve a merge of some files in
favor of their versions, regardless of whether the file is binary.
You're now requiring that user or script to consider binary-ness in
order to use the UI, no?
--Pete
23 matches
Mail list logo
