Hello Mark!
I can think of a third option and that is
3) Make the branch, make the updates in the property. Pop up a commit
window (where the commit message can be given) where the user can choose
"OK = commit and then switch", "throw away breadcrums" (corresponding to
alternative 2 in your mail), or "Cancel = don't do Switch".
Otherwize alternative 1) sounds fine to me.
There is another aspect of this and that is the authorization issues and
how I plan to set it up for the ArgoUML Open Source project. My plan is
to have only "core commiters" to commit to trunk while any contributor
is allowed to create branches and commit to the branch. It would be nice
if the "core commiter" eventually doing the merge could quickly find the
branch in the list of branches instead of having to browse down the
tree. I guess the requirement to commit a property change in trunk will
be a problem either for me trying to figure out how to configure the
setup to allow contributors to commit changes just to subclipse:tags and
nothing else, or for the contributors and developers that will not be
able to store this information in the repository.
I see no simple solution to this. I am expecting Subversion 1.5 to solve
this with all the talk about keeping track of branches and merges and I
understand I can't expect a solution before that.
/Linus
Mark Phippard wrote:
> On Dec 6, 2007 4:31 PM, Linus Tolke <linus@tigris.org> wrote:
>
>
>> If I check the "Switch working copy to new branch/tag" while creating a new
>> branch, I notice that the "breadcrum", i.e. the update of the subclipse:tags
>> property of the project ends up in the branch and not in the trunk.
>>
>> This is not very convenient since the features provided by the
>> subclipse:tags does not work:
>> * It is not possible to look at the history and see where the branch was
>> made.
>> * It is not possible for my collaborating friends to quickly find the branch
>> and switch to it.
>>
>> Hence-forth I will recommend to my developer group that we don't use the
>> "Switch working copy to new branch/tag" but instead leave it unchecked,
>> commit in the main branch, and then switch.
>>
>> Is this taken care of by an issue or should I file it? Issue 471 has some
>> similar reasoning but that is not expressed as a problem.
>>
>
> Well, it would be taken care of by issue 471, but I do not expect that
> issue to be done. I'd suggest filing another issue. There are two
> things we could possibly do:
>
> 1) Do not expose that checkbox if the subclipse:tags property is set
> on the item you are branching.
>
> 2) If we leave the checkbox, and the user checks it, do not do the
> subclipse:tags processing after creating the branch.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Fri Dec 7 23:08:56 2007