[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: The "follow copy history" initiative

From: C.A.T.Magic <c.a.t.magic_at_gmx.at>
Date: 2004-04-02 02:30:03 CEST

Greg Hudson wrote:
> On Thu, 2004-04-01 at 15:21, Ben Collins-Sussman wrote:
>>** And in some ideal future, we'd get back one of
>> 1. "object doesn't exist by any name in rFUTURE."
>> 2. "object exists at N different locations in rFUTURE, please try
>>again using one of these URLs:"
> No, I never said that. With proper rename tracking, an object can exist
> in at most one place in the future. A copy of the object doesn't count.

Maybe if there was a -tiny- difference between a normal 'cp'
and a 'cp to create a branch', some things would be a lot easier?
I'm thinking of something like
   svn cp --branch (reposurl)/A/ (reposurl)/branches/A-branch/
   (alias svn branch?)
which could add a small marker (or property) to the new
copy to tell that it is a new -branch-.
this way you could distinguish which file to follow on a rename and
which not.
    svn cp (reposurl) A/ B/
        # a 'normal' rename, follow it on 'future' searches
    svn mv (reposurl) A/ B/
        # a 'normal' move, follow it on 'future' searches
    svn cp --branch (reposurl) A/ B/
        # a -special- copy, don't follow it unless told to
    svn cp --tag (reposurl) A/ B/
        # a -special- copy, don't follow it unless told to
        # additionally marks the target as readonly.

Or maybe a custom configured option could automatically
assume --branch if the source and destination url of a
'svn cp' match a certain pattern.
Maybe such a special --branch property could also make it easier to
automatically search for branches that need merge into trunk.
I know all this can be done by 'manually' looking at the
urls, but automated tools that don't "know" about the decided
(/trunk /tags /branches) repository structure could have it
much easier then.
A "cp --tag" option could additionally give the target folder
a 'read only' property to prevent accidental commits to it.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 2 02:30:18 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.