Well, I attached the files renamed to *.script and it apparently worked.
Seems like *.sh endings are rejected, solely by name.
Karl Fogel wrote:
> Neels Hofmeyr <neels_at_elego.de> writes:
>> And the mail server swallows *.sh files. Great. Trying again.
>
> I noticed several block messages from you (I'm one of the moderators),
> with names like "root_conflict3.sh" and such. I have no idea why they
> got blocked, unless the system actually bases it on the name of the
> file, which would seem silly, but is, I suppose, possible.
>
> If you can't attach them, putting them inline is the way to go, I
> guess. Seems you did that. Sorry for the trouble.
>
> -Karl
>
>> Neels Hofmeyr wrote:
>>> Julian Foad wrote:
>>>> On Fri, 2008-09-05 at 04:25 +0200, Neels Hofmeyr wrote:
>>>>> Quoting:
>>>>>
>>>>> * subversion/libsvn_wc/update_editor.c
>>>>> (bump_dir_info): Update a doc-string to allow for a directory to have tree
>>>>> conflicts.
>>>>> (entry_has_local_mods, check_tree_conflict): New functions.
>>>>> (do_entry_deletion): Have the parent's admin access baton passed in by the
>>>>> caller. Check for tree conflicts.
>>>>> ### Broken when parent_adm_access is NULL.
>>>>>
>>>>>
>>>>> I've already posted a fix for this one almost two weeks ago. It wasn't being
>>>>> heard much.
>>>> That's my fault, Neels. I read your message then, and the earlier ones,
>>>> and started to reply, but lost my way. Sorry.
>>>>
>>>>> So I'm posting an update, using today's tree-conflicts branch, compacting my
>>>>> explanations. You may refer to the following mail for more (confusing) detail:
>>>> Excellent. Thanks.
>>>>
>>>>> http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=142154
>>>>> Date: Sat, 23 Aug 2008 22:43:11 +0200
>>>>> From: Neels Hofmeyr <neels_at_elego.de>
>>>>> Subject: Re: Tree-conflicts branch - log message / review
>>>>>
>>>>>
>>>>>
>>>>> Two problems coincide:
>>>>>
>>>>> 1. Tree conflict detection is skipped when examining the path that was
>>>>> specifically given as target. E.g. `svn update A/D/G' means that while G's
>>>>> contents are checked for tree conflicts, G itself will not be checked.
>>>>>
>>>>> 2. Tree conflict detection segfaults if run in that situation given in point
>>>>> 1 above.
>>>>>
>>>>>
>>>>> This patch fixes both, plus it tweaks two "unrelated" cmdline test to ignore
>>>>> a 'C' marker caused by the fix. The fix itself consists of three parts:
>>>>>
>>>>> i) A change made in the tree-conflicts branch is reverted to trunk:
>>>>> do_entry_deletion() does not need a PARENT_ADM_ACCESS parameter. It was
>>>>> being used to indicate the specific case mentioned in point 1 above, so as
>>>>> to be able to skip tree-conflicts detection in that case, oddly enough. Stsp
>>>>> has pointed out that this change must have been committed by accident.
>>>> Heh. It was me who added that. It wasn't by accident. I was trying to
>>>> solve the problem of when the target is the root of the WC and therefore
>>>> there is no parent WC directory. However, I didn't properly solve that
>>>> problem, and I forgot to mention it in the log message, so we might very
>>>> well call it an accident.
>>> lol, sorry and thanks :)
>>>
>>> But, about when the target is the working copy root: that got me thinking.
>>> There is no parent directory to report conflicts in! And what will
>>> adm_retrieve return in such a case?
>>>
>>> This is the exact case:
>>> 1. Directory X has been issued on the svn commandline (e.g. `svn update X')
>>> 2. This directory X is a tree-conflict victim, and
>>> 3. X also happens to be the root of the local working copy.
>>>
>>> (It doesn't make sense to think of the repository root being a tree
>>> conflicts victim. Here, though, X has been checked out explicitly, and is
>>> the working copy root, as one would check out `trunk')
>>>
>>> There has been word that tree conflicts should be reported at the actual
>>> victim nodes, not in their respective parent directories. That would
>>> sufficiently prevent this problem altogether.
>>>
>>> But for now, I tried to create conflicts in a working copy's root dir. It
>>> seems that at least update is waterproof, in a way. I've attached scripts
>>> that run the cases listed here, numbers corresponding:
>>>
>>>
>>> 1) Try to update the working copy root to a deleted revision (no conflicts):
>>> "svn: Target path does not exist"
>>>
>>> 2) Prop conflicts are handled as they should.
>>>
>>> 3) Run `svn rm .' in the working copy root and try to commit:
>>> States that the commit succeeded but warns about ugly problems.
>>> Status complains about a "missing" file removed by svn itself.
>>>
>>> 4) First run `svn rm .' in the working copy root, then try to update it to a
>>> deleted revision: same as 1): "svn: Target path does not exist".
>>> Also, `svn rm .' fails to lock a subdir, whatever that means.
>>>
>>> 5) First run `svn rm .' in the working copy root, then try to update it to a
>>> modified revision: same as 3): commit succeeded but warns about ugly
>>> problems. Also, the update "restores" a file removed by svn itself.
>>>
>>>
>>> It is pretty obvious that these cases are not considered valid. At least no
>>> user out there will run into the problem I am poking for here, because it
>>> doesn't even run that far, for other reasons.
>>>
>>> Have I missed a case? Otherwise everything is fair enough, at least from the
>>> tree-conflicts point of view ... switch and merge remain to be checked, but
>>> I expect the same stuff happening.
>>>
>>>
>>>
>>>> I made just one tweak: There was a point where you wrote "if
>>>> (svn_io_check_path(...) != SVN_NO_ERROR ..." which would leak the error
>>>> object if it threw an error. Instead, we have to call the function on
>>>> its own, as "SVN_ERR(svn_io_check_path(...));". Any error that it might
>>>> return is one that we don't know how to deal with, so it is OK to just
>>>> return the error to our caller.
>>> Ah yes, true. (Hasn't this been said before somewhere, too?)
>>> I checked and yours is better. I had assumed that the SVN_ERR indicates a
>>> missing directory, but duh.
>>>
>>>
>>>> Committed in r32932.
>>> Thanks!
>>>
>>> ~Neels
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
>
--
Neels Hofmeyr -- elego Software Solutions GmbH
Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23458696 mobile: +49 177 2345869 fax: +49 30 23458695
http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelsreg: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
Received on 2008-09-09 05:26:13 CEST