You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@xbc.nu> on 2001/11/21 17:32:52 UTC
Re: Moving C to its own directory (was Re: ObjC tree inlining)
Zack Weinberg wrote:
>On Tue, Nov 20, 2001 at 08:25:54PM -0500, Phil Edwards wrote:
>
>>On Tue, Nov 20, 2001 at 05:13:15PM -0800, Zack Weinberg wrote:
>>
>>>I say if we wait about another six months Subversion[1] will be usable
>>>enough that we can scrap CVS, and then we'll have a version control
>>>system that actually understands renaming files.
>>>
>>Wow, are they that far along? It's been a while since I looked... Shoot,
>>if Subversion is a viable replacement within the next several months,
>>I'm more than willing to wait.
>>
We're pretty far along the road. We've been self-hosting for about two
months now, without major problems (and no data loss).
>Yeah, they're on track to have something viable around the same time
>we kick 3.1 out the door. The status page says that they're at 0.6,
>with "svn mv" and "svn cp" already working on files, and lists
>upcoming releases:
>
> * Subversion 0.7 (Mon 3 Dec 2001): Branching and tagging.
>
> * Subversion 0.8 (Thu 20 Dec 2001): "Simple" merging
> (ancestry-sensitive merging is optional for this
> milestone). Diffs on network in both directions.
>
> * Alpha (TBD): Most commonly used features completed.
>
> * Beta (TBD): Release candidate, heavy testing. Possible inclusion
> of newer, less popular features.
>
> * 1.0 Release (TBD): Release.
>
>I'm a bit nervous about the number of weird libraries with unstable
>interfaces they want (neon, APR),
>
APR is shared by Apache 2.0, and will be release-quality long before
Subversion.
Neon is a bit different
> and wonder if the client will wind
>up being as portable as we need it to be.
>
The client has been tested on at least 13 different platfotms to date.
You can get the list directly from the SVN repository on
http://svn.collab.net/repos/svn/trunk/PORTING, although note that it's
not quite up-to-date.
> They do seem aware of the
>issues, and they've got *BSD people on the team so at least it won't
>be all-the-world-is-Linux crap.
>
Heh. I 've been doing all my development with MSVC on Windows lately, so
we're also safe from the all-the-world-is-gcc crap. :-)
>When they get to beta I may do some trial conversions of our existing
>repository, time permitting.
>
We'll need a converter for that. cvs2svn is planned (for Beta, I think),
but it's not very far along. Volunteers are welcome. :-)
--
Brane �ibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Moving C to its own directory (was Re: ObjC tree inlining)
Posted by Zack Weinberg <za...@codesourcery.com>.
On Wed, Nov 21, 2001 at 05:58:54PM -0600, Karl Fogel wrote:
>
> There have been various proposals for a Subversion module system,
> along the lines of "union directories", or other indirection-based
> systems that allow rule-based groupings. That would probably solve
> the problem described above, but it will not be in 1.0.
>
> On the other hand, Subversion will support symlinks / shortcuts, which
> should alleviate the problem...
Let me attempt to illustrate how GCC currently uses modules and how I
think that might map to a subversion repository, and you can tell me
if I'm all wet.
The gcc tree is laid out like this:
/cvs/gcc/gcc/ # core code needed always
libiberty/
include/
configure
...
gcc/cp/ # C++ front end and libraries
libstdc++/
gcc/java/ # Java front end and libraries
libjava/
boehm-gc/
...
Each of these blocks is a CVS module: checking out gcc-core gets you
no more than you need to build a C compiler, gcc-core + gcc-cp gets
you C++ as well, etc. Checking out "gcc" gives you the whole
enchilada.
Now, you say Subversion doesn't have a feature directly equivalent to
CVS modules, but it does have in-repository symbolic links. I could
lay out the file system like this:
/subv/gcc/PHYSICAL/libiberty/
include/
gcc-core/
gcc-cp/
gcc-java/
libstdc++/
libjava/
...
/subv/gcc/all/ libiberty -> ../PHYSICAL/libiberty
gcc -> ../PHYSICAL/gcc-core
gcc/cp -> ../../PHYSICAL/gcc-cp
...
/subv/gcc/core/ libiberty -> ../PHYSICAL/libiberty
gcc -> ../PHYSICAL/gcc-core
...
And ideally, when I checked out "all" or "core", the server would
traverse the symlinks and I'd get a working copy that appeared to have
the cp directory as a direct child of gcc/. Also, on future update
operations, the server would notice additions to the shadow tree I'm
in, but not pick up PHYSICAL modules not referenced from that tree.
Two problems: first, I've got a symlink as a child of a symlink in
the above illo, which is probably impossible. Second, how do I check
out "gcc-core gcc-cp" and get just the core and the C++ compiler? We
don't want a combinatorial explosion of these shadow trees.
zw
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Moving C to its own directory (was Re: ObjC tree inlining)
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Zack Weinberg <za...@codesourcery.com> writes:
> There's a related problem, which we have now with CVS in the src
> repository, but would get worse if they were merged. CVS does not
> remember which module(s) you originally selected when you checked out
> a tree. Therefore, if you use the -d option, it checks out the entire
> repository the first time you try to update a working copy containing
> a subset of the tree. But if you don't use the -d option you don't
> get _any_ new subdirectories unless you specifically ask for them, and
> you may not know which they are.
>
> It would be nice if Subversion did this better.
I'm not sure it does (yet), except in that it versions directories,
but I don't think that exactly solves what you're talking about.
There have been various proposals for a Subversion module system,
along the lines of "union directories", or other indirection-based
systems that allow rule-based groupings. That would probably solve
the problem described above, but it will not be in 1.0.
On the other hand, Subversion will support symlinks / shortcuts, which
should alleviate the problem...
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Moving C to its own directory (was Re: ObjC tree inlining)
Posted by Zack Weinberg <za...@codesourcery.com>.
On Wed, Nov 21, 2001 at 11:15:54PM +0000, Joseph S. Myers wrote:
>
> Can the Subversion version model handle multiple past development
> mainlines merging into one future mainline?
>
> We have at present the separate "gcc" and "src" repositories, which share
> some files - and some people would like to merge these into a single
> repository, but it would be desirable still to be able to check out either
> past tree on any tag or date from before the merge.
There's a related problem, which we have now with CVS in the src
repository, but would get worse if they were merged. CVS does not
remember which module(s) you originally selected when you checked out
a tree. Therefore, if you use the -d option, it checks out the entire
repository the first time you try to update a working copy containing
a subset of the tree. But if you don't use the -d option you don't
get _any_ new subdirectories unless you specifically ask for them, and
you may not know which they are.
It would be nice if Subversion did this better.
zw
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org