You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by pe...@arm.com on 2001/08/01 11:22:32 UTC
Re: Intro and questions
On 2001-07-31 19:56:08 Justus Pendleton wrote:
>On Tue, Jul 31, 2001 at 06:52:22PM +0100, peter.westlake@arm.com wrote:
>> >> one where the sub-module would be thought of as "part of" the parent
>> >> module, and branched with it
>> >
>> >Why don't subdirectories suffice for this?
>>
>> In addition to the reason Mark gave (separate version histories),
>> subdirectories can't be shared.
>
>Huh? Sure they can. I do it all the time with perforce:
>
>View:
> //asgard/web/... //washuu/dreamweaver/...
>
>If you can't share directories or other arbitrary sets of files
>independent of the entire project that is a limitation of the tools
>involved; it has nothing to do with directories per se.
I think we may be talking at cross-purposes. What I mean is that
if we have two programs foo and bar that both use a library lib,
and I check out foo, giving me:
foo/foo.c
foo/lib/lib.c
and I edit foo/lib/lib.c and check it in,
you should then be able to check out bar and get
bar/bar.c
bar/lib/lib.c
with my changes to lib.c. I haven't seen anything in the
Subversion documentation to suggest that this can be done.
Peter.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Intro and questions
Posted by Ben Collins-Sussman <su...@collab.net>.
Yoshiki Hayashi <yo...@xemacs.org> writes:
> <pe...@arm.com> writes:
>
> > I think we may be talking at cross-purposes. What I mean is that
> > if we have two programs foo and bar that both use a library lib,
> > and I check out foo, giving me:
> >
> > foo/foo.c
> > foo/lib/lib.c
> >
> > and I edit foo/lib/lib.c and check it in,
> > you should then be able to check out bar and get
> >
> > bar/bar.c
> > bar/lib/lib.c
> >
> > with my changes to lib.c. I haven't seen anything in the
> > Subversion documentation to suggest that this can be done.
>
> If this is the goal, I think this can be implemented easily
> by adding 'link' node kind to subversion filesystem.
Yoshiki is right. We do intend to support symbolic links in the
filesystem someday. It seems like this is all we'd need.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Intro and questions
Posted by kf...@collab.net.
Branko =?ISO-8859-2?Q?=C8ibej?= <br...@xbc.nu> writes:
> >2. Since Subversion will version real symlinks in the expected way,
> >
>
> Ouch. What is the expected way on systems that don't support symlinks?
> For instance: if xou check in a symlink on Unix, and check out on Win32,
> what happens?
Nobody knows. Your suggestions are welcome. :-)
(I thought Windows had shortcuts? Are they different from symlinks?)
One answer might be to store the link target as the file's contents,
but keep the entry marked as type "symlink".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Intro and questions
Posted by Ben Collins-Sussman <su...@collab.net>.
Branko =?ISO-8859-2?Q?=C8ibej?= <br...@xbc.nu> writes:
> Ouch. What is the expected way on systems that don't support symlinks?
> For instance: if xou check in a symlink on Unix, and check out on Win32,
> what happens?
Ummmmm.... create an Explorer "shortcut"? (*.LNK)?
I wonder how apr_file_io.h treats symlinks on Win32...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Intro and questions
Posted by Branko Čibej <br...@xbc.nu>.
kfogel@collab.net wrote:
>2. Since Subversion will version real symlinks in the expected way,
>
Ouch. What is the expected way on systems that don't support symlinks?
For instance: if xou check in a symlink on Unix, and check out on Win32,
what happens?
Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Intro and questions
Posted by kf...@collab.net.
Greg Stein <gs...@lyra.org> writes:
> > Again, this is definitely post-M3. :-)
>
> Euh... my understanding was post-1.0. I think it would be wrong to imply
> that we are going to attempt anything like this for 1.0.
>
> "Do we need that *now*?" "No." "Punt it to after 1.0"
Sorry, yeah, it's also post-1.0, and it would have been more
informative for me to put it that way (I mean, it is therefore also
post-M3, but that's a confusing way to phrase it :-) ).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Intro and questions
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Aug 03, 2001 at 12:17:02PM -0500, kfogel@collab.net wrote:
...
> A couple of things, to avoid confusion:
>
> 1. The fs doesn't have copy nodes, now. See the description in
> subversion/libsvn_fs/structure for how copies were implemented
> -- basically, there's a non-historical property on a node
> revision saying what that noderev was copied from.
>
> 2. Since Subversion will version real symlinks in the expected way,
> we should be careful to avoid using the same term for the
> unrelated feature Yoshiki describes above. (Mike, Ben, and I
> have been calling them "vnodes" or "virtual entries", but maybe
> a better name will suggest itself?)
>
> Again, this is definitely post-M3. :-)
Euh... my understanding was post-1.0. I think it would be wrong to imply
that we are going to attempt anything like this for 1.0.
"Do we need that *now*?" "No." "Punt it to after 1.0"
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Intro and questions
Posted by kf...@collab.net.
Yoshiki Hayashi <yo...@xemacs.org> writes:
> <pe...@arm.com> writes:
> > I think we may be talking at cross-purposes. What I mean is that
> > if we have two programs foo and bar that both use a library lib,
> > and I check out foo, giving me:
> >
> > foo/foo.c
> > foo/lib/lib.c
> >
> > and I edit foo/lib/lib.c and check it in,
> > you should then be able to check out bar and get
> >
> > bar/bar.c
> > bar/lib/lib.c
> >
> > with my changes to lib.c. I haven't seen anything in the
> > Subversion documentation to suggest that this can be done.
>
> If this is the goal, I think this can be implemented easily
> by adding 'link' node kind to subversion filesystem. It's
> like symoblic link in fs. Subversion already has copy node
> to do cheap copy. To retrieve contents, copy nodes and link
> nodes work exactly the same way. It will behave as if its
> node is the linked one. The only difference is commiting
> the change. Commiting to copied node won't touch linked
> node. The ordinary node will be created for its place. If
> you commit to link node, link node won't be changed. The
> linked node will be changed and link node will continue to
> point to the same path.
>
> Then you can say something like
>
> svn ln -s bar/lib foo/lib
>
> and achieve what you have described.
>
> I don't know the implications with regard to authentication
> etc. but this seems to be the easiest solution to me.
>
> (Not having followd subversion development closely for 4
> months and hoping my knowledge is not outdated yet. I've
> just finished the first semester of graudate school. I'd
> like to help subversion project but I'm heading to vaction
> in a few days...)
Glad to see you back, Yoshiki! Hope grad school isn't eating all your
time...
Yes, the system you describe is exactly along the lines of what we
have been thinking, though it's good to have your concrete
description.
A couple of things, to avoid confusion:
1. The fs doesn't have copy nodes, now. See the description in
subversion/libsvn_fs/structure for how copies were implemented
-- basically, there's a non-historical property on a node
revision saying what that noderev was copied from.
2. Since Subversion will version real symlinks in the expected way,
we should be careful to avoid using the same term for the
unrelated feature Yoshiki describes above. (Mike, Ben, and I
have been calling them "vnodes" or "virtual entries", but maybe
a better name will suggest itself?)
Again, this is definitely post-M3. :-)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Intro and questions
Posted by Yoshiki Hayashi <yo...@xemacs.org>.
<pe...@arm.com> writes:
> I think we may be talking at cross-purposes. What I mean is that
> if we have two programs foo and bar that both use a library lib,
> and I check out foo, giving me:
>
> foo/foo.c
> foo/lib/lib.c
>
> and I edit foo/lib/lib.c and check it in,
> you should then be able to check out bar and get
>
> bar/bar.c
> bar/lib/lib.c
>
> with my changes to lib.c. I haven't seen anything in the
> Subversion documentation to suggest that this can be done.
If this is the goal, I think this can be implemented easily
by adding 'link' node kind to subversion filesystem. It's
like symoblic link in fs. Subversion already has copy node
to do cheap copy. To retrieve contents, copy nodes and link
nodes work exactly the same way. It will behave as if its
node is the linked one. The only difference is commiting
the change. Commiting to copied node won't touch linked
node. The ordinary node will be created for its place. If
you commit to link node, link node won't be changed. The
linked node will be changed and link node will continue to
point to the same path.
Then you can say something like
svn ln -s bar/lib foo/lib
and achieve what you have described.
I don't know the implications with regard to authentication
etc. but this seems to be the easiest solution to me.
(Not having followd subversion development closely for 4
months and hoping my knowledge is not outdated yet. I've
just finished the first semester of graudate school. I'd
like to help subversion project but I'm heading to vaction
in a few days...)
--
Yoshiki Hayashi
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org