> Date: Mon, 16 Jun 2008 12:51:19 +0100
> From: simon.tortoisesvn_at_googlemail.com
> To: users_at_tortoisesvn.tigris.org
> Subject: Re: SVNCopy from within TortoiseSVN
>
> 2008/6/16 tejo dorus :
>>
>>
>> As far as I can see, it (TSVN) should do exactly what the svncopy script
>> does.
>
> But you haven't said what that is.
The exact behaviour of the svncopy.pl script is found in http://svn.collab.net/repos/svn/trunk/contrib/client-side/svncopy/svncopy.pl.in . What I expect to be done is:
TAGGING:
* Check out the tree and create a copy
* For each "externals definition": find the head revision number in the external repository
* Update the "externals definitions".
* Commit
BRANCHING (seems only to be working for "internals" (externals within the same repository)):
1. (Locally) copy the tree (ex: /Project/Project_Foo/Trunc) to the branch folder (ex: /Project/Project_Foo/Branch/BugFix)
2. (Locally) copy the "internals" (ex: /Project/Common) to the branch folder (ex: /Project/Project_Foo/Branch/BugFix/_Common)
3. (locally) update the externals definition, so that /Project/Project_Foo/Branch/Bugfix/Common points to /Project/Project_Foo/Branch/Bugfix/_Common.
4. Commit
For step 2, the user should be able to choose which ones of the "internals" should be branched, and which ones should simply be tagged or perhaps remain pointing to the head revision. I imagine some kind of a checkbox list that contains all externals for a given project (recursively obtained), and in which the user can select which ones to branch, which ones to tag, and which ones to leave pointing to the head revisions. Maybe it is possible to combine tagging and branching in one nice-to-use dialog window because they are so similar. You click on a folder, the dialog window inspects the tree for externals and asks for each external what to do, and then, after selecting the target folder, the process begins.
>
>> Behaviour for tagging is straightforward: it must tag exactly the
>> version number of the current externals head revision.
>
> OK, that sounds sort-of reasonable, although if a particular revision
> is not set it means contacting the external's repository to find the
> HEAD revision. What happens if the external repo is offline? Should
> the operation fail?
Yes, in that case, the operation should fail, or the user should be asked whether to abort (fail) or continue, in which case the external definitions are not altered and still point to the head revision.
>
>> Fro branching, it is
>> slightly more complicated, but the key point is that a copy of the externals
>> head revision is to be created.
>
> I don't understand this point. You say it is more complicated, but you
> don't say what you expect it to do. Are you saying that we also have
> to create a branch within the external's repo to match the branch in
> the working repo? That will not be the right behaviour in a lot of
> cases. For example TSVN uses the Neon and Subversion libraries and we
> do not want to create branches of those, and we do not have commit
> access to those repos anyway.
I agree that it would not be good to create a branch in the externals repo. See my comments on BRANCHING above. The suggested approach for branching only works properly for "internal repositories". If it would be used on external repositories, a hard copy of the external data would be added to SVN each time a branch is made, which is okay if this really is what the user wants, but most of the times will not be the intention.
>
>>> Externals by definition refer to some external object, so it
>>> is likely they would not be changed anyway.
>> I do not quite understand this remark. Do you mean that the external
>> definitions do not change, or that the underlying external data does not
>> change?
>
> The first one.
>
>> The "external definitions" do normally not change, but for tagging, it is
>> important that the current head revision number gets included in the
>> "externals definition".
>
> Agreed. That has to be done by the user right now. If you relocate
> your repository, or if the externals repo is relocated, that is also a
> change you have to do manually. SVN support for updating externals is
> not very comprehensive.
>
>>> Note that SVN 1.5 will have support for relative external paths, which
>>> can be relative to various points:
>> This is very ncie feature, which makes life much easier for sharing common
>> code. I am very happy with this feature. Imho, if TSVN would, in addition to
>> this great new feature, also support branching/tagging with externals, it
>> would be extremely powerful. At the moment, not being able to perform easy
>> branching/tagging with externals is the only no-go for us to start using
>> (T)SVN.
>
> Simon
>
> --
> : ___
> : oo // \\ "De Chelonian Mobile"
> : (_,\/ \_/ \ TortoiseSVN
> : \ \_/_\_/> The coolest Interface to (Sub)Version Control
> : /_/ \_\ http://tortoisesvn.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
> For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
>
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
Received on 2008-06-16 17:39:27 CEST