>> While I could personally live with that behavior, even if it is
>> annoying, the really bad thing is that it breaks our existing scripts
>> and basically prevents me from upgrading to SVN 1.6 on any machine that
>> has to run such a script.
>>
>
> I'm starting to wonder if you could simply choose to leave the unused
> directory in place on the branch and ignore it? If it's not modified
> on the branch anyway it should always receive changes from trunk cleanly
> and not be much of a bother.
>
> You mentioned that the content of the directory should not be visible to
> people working on the branch, but how important is this, really? Is it
> important enough to justify the merging problems it creates, and is it
> worth preventing an upgrade to 1.6? And note that svn rm won't protect the
> directory from visibility by people working on the branch anyway because
> they have access to the history of the branch, so you're probably using
> a wrong solution to your problem already.
>
> You could also move the offending directory somewhere else in the
> repository, protect it and trunk properly using authz instead of svn rm,
> and if necessary make it accessible in trunk again at its old place
> using a directory external.
> But before you jump into using authz, make sure to read
> "Do You Really Need Path-Based Access Control?" in the svnbook:
> http://svnbook.red-bean.com/en/1.5/svn.serverconfig.pathbasedauthz.html
> And make sure to take a look at issue #3242:
> http://subversion.tigris.org/issues/show_bug.cgi?id=3242
> (tigris.org's web server seems to be down right now...)
>
No, I've already decided against this possibility. I don't want to mess
around with the server setup and its admins.
> If you really want to stick with your current approach I'm afraid you
> will need to adjust those scripts that are breaking or stay stuck
> with Subversion 1.5 forever. To fix the scripts, you could automate
> something like "svn resolve --accept=working" on all affected items
> if that produces the desired result.
>
> If you can, I would really recommend to just leave the directory on
> the branch for people to see and ignore. This is the simplest solution.
>
You're right in principle. The problem in this special case is not so
much a technical one but an organizational. The resulting checkout goes
into a production environment where people don't have much in mind with
version control. Every change causes much questioning and paperwork.
That's the main reason, I want to keep the visible amount of change at a
minimum. There should have been an intermediate step, which performs the
checkout and afterwards distributes files as necessary, but alas! Well,
I think this is getting a bit OT ;)
[...]
> I'd rather not see svn:ignore abused for dealing with tree conflicts,
> because that implies that it suddenly has meaning for versioned items.
> Especially if a better solution is known, like the already suggested
> configurable tree conflict handling policy.
>
That's true of course. Nevertheless, I think the current behavior is
quite strange:
You get a tree conflict on the removed and ignored directory and cannot
resolve it unless you remove svn:ignore for the affected item.
That's not the way it should work, although I have no idea how to handle
such a situation correctly.
The problem simply arises from the fact that tree conflicts were
introduced before the handling policy was fully in place. Although I
like the idea of tree conflicts in general, it might have been a good
idea to provide an update/merge option which simply doesn't generate any.
Be it good or bad, at least where I work quite a number of scripts (most
of which still based on CVS) rely on the fact that a branch which
contains removed items can be updated without problems. Until now,
migration went rather smoothly and many things became simpler, but now I
see problems creeping up.
>
>> Sometimes it would be rather helpful anyway to exclude certain items
>> from a merge. I think this could be controlled in a similar way.
>>
>
> That idea opens yet another can of worms -- merge-tracking :)
>
Right. A favorite of mine ;)
Bernhard
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2117268
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-08 19:47:07 CEST