RE: Revision # theorhetical upper limit

> andy.glew@amd.com wrote:
>
> >(Unfortunately, Subversion branching is more painful than CVS
> >branching, because Subversion branching requires more Makefile
> >changes.)
> >
> >
> > [Branko Cibej]
> I don't understand, why would it require any makefile changes at all?

Reid Spencer [reid@x10sys.com]
>Properly written makefiles that always use paths relative to the current
>directory should be fine. If the makefiles aren't written that way then
>problems can occur because a Subversion branch is simply a copy (or
>apparently so) to another location. For example, most repositories are
>laid out like:

As I mentioned earlier, I started writing a longer reply,
got interrupted, and will complete and send it when
I get back to work (no &^$%&^&%&%^&^ VPN remote access).

Briefly:

   Branching in CVS is easy because it does not
   change the location of the files.
   Branches and location in the tree are separate.

   This applies particular to incomplete branches
   embedded in a larger amount of code to which
   the branch tag is not applied (indeed, may not
   be allowed to be applied to).

   E.g. with repository
        CVSROOT/proj/{module1,module2}
   checked out as
        workspace/proj/module1
   branch module1 using
        cvs tag -b foo-branch workspace/proj/module1
   but note that the rest of proj is not branched.

   However, you can easily check out the mixed
   combination of foo-branch for module1 and HEAD
   for the rest of proj, by doing
         cvs co -f -r foo-branch proj
   i.e. it is trivial to move a combination of
   branched and HEAD through the repository.

   In particular, it is easy to do so for & modules.

With Subversion, on the other hand,

   (a) if you branch all of the repository things
       work okay - except that you have to merge
       a lot of files that you just want to track HEAD
       on

   (b) it is easy to create a mixed workspace
       which avoids the unnecessary merging

   (c) but it is hard to tell someone else how to
       check out a combination of HEAD and the branched
       files or modules.
           You either have to give them a fairly annoying
       recipe to build a mixed workspace
           svn co -r HEAD http://svnserve/proj/trunk projws
           cd projws
           rm -f module1
           svn co -r HEAD http://svnserve/proj/branch/foo-branch/module1 module1
       
      Or, you change your Makefile.
           

Similarly, with Subversion, TTBOMK, svn:external
must contain absolute URLs.

If I have
    http://svnserve/proj1/trunk/{module1,module2}
    http://svnserve/proj2/trunk
        with external dependency
        http://svnserve/proj2/trunk/import/module1
        on
        http://svnserve/proj1/trunk/module1

When I branch module1, I feel obliged to test this
branch with all of the projects that depend on it.
I therefore need to check out a mixed workspace
of proj2 HEAD and proj2/import/module1 foo-branch.

But since the svn:external contains absolute paths,
I have to go in and edit svn:externals to do so:
again, there is not a simple command that allows
me to check out proj2 HEAD overlaid with module1 foo-branch.

---
Getting back to Reid's point: it is not my Makefiles that
contain absolute paths.  It is svn:externals that contains
the absolute paths.
Either these absolute paths must be edited by hand, or,
I can use Makefile magic to patch it over.   But I have
still not found a really painless way.
---
Meta-comments:
SubVersion branching works best if you branch *everything*
that might possibly need to be built with the branch.
(But this leads to constant merge tracking.)
SubVersion branching does not work so well, so far as
I have been able to figure out, when you only want to branch
a submodule.
Subversion does not make it easy to copy overlaid
or mixed contous, e.g. HEAD + a branch, through the
repository.
SubVersion uses too many absolute URLs, e.g. in svn:externals.
As Reid commened about Makefiles, absolute pathnames of any form
create position dependent configurations.
---
Hmmm..... this was about all I wanted to say.
Maybe I won't send the interrupted email.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org