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 2002/05/14 22:23:35 UTC
Re: svn commit: rev 1957 - trunk/subversion/include trunk/subversion/libsvn_wc
kfogel@tigris.org wrote:
>Author: kfogel
>Date: 2002-05-14 21:35 GMT
>New Revision: 1957
>
>Modified:
> trunk/subversion/include/svn_types.h
> trunk/subversion/libsvn_wc/entries.h
>Log:
>Starting module system, issue #517:
>
>* subversion/include/svn_types.h
> (SVN_PROP_MODULE): New property.
>
>* subversion/libsvn_wc/entries.h
> (SVN_WC__ENTRY_ATTR_MODULE): New entry attribute...
> (SVN_WC__ENTRY_MODIFY_MODULE): ...And new modification flag for it.
>
>
Just a minute. Are you doing all this work /instead/ of adding reference
nodes to the filesystem? And this will all get ripped out once we have
reference nodes? Sorry, but I don't like that at all.
I also didn't find any design doc for this feature, discussing pros and
cons and tradeoffs vs. reference nodes. I only remember one or two posts
to the dev list, without any real conclusions.
(Can you point me to the relevant messages if I missed them? Thanks.)
-1
--
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: svn commit: rev 1957 - trunk/subversion/include trunk/subversion/libsvn_wc
Posted by Greg Stein <gs...@lyra.org>.
On Wed, May 15, 2002 at 12:56:08AM +0200, Branko Äibej wrote:
> Greg Stein wrote:
>...
> >The reference nodes are a different concept. While they might be able to do
> >inter-repository "modules", they won't be able to do intra-repos modules.
> >If/when those nodes arrive, the client-side modules would remain.
>
> (I'm guessing you meant just the opposite: Will be able to simulate
> modules within the same repository, but not from other repos?)
My understanding of any kind of new node in the FS would be that it refers
to internal items, rather than external pointers. So yah.. maybe I got my
"inter" vs "intra" mixed up; basically, I was saying that a ref node design
wouldn't be able to refer to other/arbitrary repositories.
> I don't see this limitation. Since we haven't discussed reference nodes
> much at all, it's not surprising we have different models in mind.
True enough :-)
> >This approach is also a great way to handle modules. It is very user
> >approachable/editable (heck, even under revision control), and can easily be
> >handled entirely on the client side. No funky FS tricks.
> >
> >Low dev bar. High functionality. Parity with CVS (maybe better).
>
> Using a text file to express FS metadata is bad enough, but using the
> client to implement FS functionality is evil.
I don't see modules as being an FS concept at all. That is one of the
reasons why I like this design. "modules" are all about a handy way for the
client to construct a particular working copy. Repeat: working copy.
"grab this from here. that from over there. oh, and this extra bit goes
right there."
It's all about the client and the working copy.
> Observe that you're
> already disagreeing on the semantics of the "svn:module" prop.
No. The property is no big deal. The disagreement is on property
inheritance. I say "no way [for 1.0]".
>...
> >All in the issue.
>
> Yah, saw that now, my mistake for not looking there before. But IMHO
> such discussion should be held on the dev list, and culminate in a
> document. The issue tracker is nice for tracking issues, but not for
> design discussions.
If you want to take the time to write that document, then please feel free.
You know as well as the rest of us, that time is always limited. And, as
Karl pointed out, there *was* some discussion on the list.
>...
> >Vetoes require a specific technical problem; preferably with solutions for
> >rectifying that problem. Is there something technically wrong with this
> >approach?
>
> I should have qualified that with "until this feature has been discussed
> at length". I thought I had made my objections obvious. Right now, I see
> more minuses than pluses in this feature.
I read your position as "this should be handled by reference nodes" but not
much more than that. If you're vetoing simply to stop work until more
discussion has occurred, then I'll have to raise a yellow flag :-)
[ as a general background (read: not necessarily aimed at Branko): it is
incumbent upon the vetoer to apply the necessary time to do their review,
raise technical problems / suggest alternatives, etc; a veto cannot hold
up others' work until the vetoer has more time ]
In any case, Karl has posted a longer note about the modules approach. I'd
suggest that you aim your concerns/issues/review of the (current) approach
at that branch of this thread :-)
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: svn commit: rev 1957 - trunk/subversion/include trunk/subversion/libsvn_wc
Posted by Branko Čibej <br...@xbc.nu>.
Greg Stein wrote:
>On Wed, May 15, 2002 at 12:23:35AM +0200, Branko Äibej wrote:
>
>
>>...
>>Just a minute. Are you doing all this work /instead/ of adding reference
>>nodes to the filesystem? And this will all get ripped out once we have
>>reference nodes? Sorry, but I don't like that at all.
>>
>>
>
>The reference nodes are a different concept. While they might be able to do
>inter-repository "modules", they won't be able to do intra-repos modules.
>If/when those nodes arrive, the client-side modules would remain.
>
(I'm guessing you meant just the opposite: Will be able to simulate
modules within the same repository, but not from other repos?)
I don't see this limitation. Since we haven't discussed reference nodes
much at all, it's not surprising we have different models in mind.
>This approach is also a great way to handle modules. It is very user
>approachable/editable (heck, even under revision control), and can easily be
>handled entirely on the client side. No funky FS tricks.
>
>Low dev bar. High functionality. Parity with CVS (maybe better).
>
Using a text file to express FS metadata is bad enough, but using the
client to implement FS functionality is evil. Observe that you're
already disagreeing on the semantics of the "svn:module" prop.
>>I also didn't find any design doc for this feature, discussing pros and
>>cons and tradeoffs vs. reference nodes. I only remember one or two posts
>>to the dev list, without any real conclusions.
>>
>>
>
>All in the issue.
>
Yah, saw that now, my mistake for not looking there before. But IMHO
such discussion should be held on the dev list, and culminate in a
document. The issue tracker is nice for tracking issues, but not for
design discussions.
>>(Can you point me to the relevant messages if I missed them? Thanks.)
>>
>>-1
>>
>>
>
>Vetoes require a specific technical problem; preferably with solutions for
>rectifying that problem. Is there something technically wrong with this
>approach?
>
>
I should have qualified that with "until this feature has been discussed
at length". I thought I had made my objections obvious. Right now, I see
more minuses than pluses in this feature.
--
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: svn commit: rev 1957 - trunk/subversion/include trunk/subversion/libsvn_wc
Posted by Greg Stein <gs...@lyra.org>.
On Wed, May 15, 2002 at 12:23:35AM +0200, Branko Äibej wrote:
>...
> Just a minute. Are you doing all this work /instead/ of adding reference
> nodes to the filesystem? And this will all get ripped out once we have
> reference nodes? Sorry, but I don't like that at all.
The reference nodes are a different concept. While they might be able to do
inter-repository "modules", they won't be able to do intra-repos modules.
If/when those nodes arrive, the client-side modules would remain.
This approach is also a great way to handle modules. It is very user
approachable/editable (heck, even under revision control), and can easily be
handled entirely on the client side. No funky FS tricks.
Low dev bar. High functionality. Parity with CVS (maybe better).
> I also didn't find any design doc for this feature, discussing pros and
> cons and tradeoffs vs. reference nodes. I only remember one or two posts
> to the dev list, without any real conclusions.
All in the issue.
> (Can you point me to the relevant messages if I missed them? Thanks.)
>
> -1
Vetoes require a specific technical problem; preferably with solutions for
rectifying that problem. Is there something technically wrong with this
approach?
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: svn commit: rev 1957 - trunk/subversion/include trunk/subversion/libsvn_wc
Posted by Branko Čibej <br...@xbc.nu>.
Bill Tutt wrote:
>>From: Branko Cibej [mailto:brane@xbc.nu]
>>
>>
>>In the FS, a local reference node would store the FS path (not the URL!)
>>of the target and (optionally) a revision number. If the rev number is
>>absent, the path refers to HEAD. Conflict resolution for ref nodes is
>>the same as for files.
>>
>>
>>
>
>Indeed, I'd point out here that a local reference node that's tied to a
>revision number should be stored thusly:
>TargetNodeID.TargetCopyID.TargetTxnID TargetPATH
>
>TargetPATH is only for UI helping purposes, the use of a
>TargetNodeID.TargetCopyID.TargetTxnID is a data retrieval optimization.
>
I was really thinking of something that behaves more like a symlink
within the FS. What you describe here is indeed a good implementation
for a hard link, but then you can't track HEAD with it if you put the
NodeChangeID of the target in.
>If you hadn't noticed this yet, this is the hard link that people have
>been wanting. :) It even behaves sanely in the face of copies/branches.
>
Indeed. But it's not very useful for implementing modules, /precisely/
because you can't track HEAD. That's a must.
--
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: svn commit: rev 1957 - trunk/subversion/include trunk/subversion/libsvn_wc
Posted by Branko Čibej <br...@xbc.nu>.
Bill Tutt wrote:
>More so than "svn copy /trunk/svn /tags/svn/milestone-X" is that's for
>sure. In fact, I like this much better for doing tags. I don't suppose
>this means anyone will let us rename "svn copy" to be "svn branch" now
>that we can add a "svn tag TAGPATH -r SOURCEPATH" command. ;)
>
>
Ah, Bill, those ants'll go extinct if you keep prodding the anthill like
this!
I'll let you do the convincing. :-)
--
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: Re: svn commit: rev 1957 - trunk/subversion/include trunk/subversion/libsvn_wc
Posted by Bill Tutt <ra...@lyra.org>.
> From: Branko Cibej [mailto:brane@xbc.nu]
>
> I really meant to reply sooner ...
>
> Karl Fogel wrote:
>
> >Branko Čibej <br...@xbc.nu> writes:
> >
> Coming, coming ...
>
[.....]
> > Solution B:
> > ===========
> > Reference nodes.
> >
> >
> >
> [snip stuff about symlinks]
>
[... lots more snipping]
> This is basically it, but I'll expand a bit. I think we'd need two
kinds
> of references -- local (intra-repository) and global
(inter-repository).
> Whether those are implemented using the same node type isn't important
> now. Global refs aren't necessary for 1.0, and are a huge problem by
> themselves, so I'll ignore them.
>
> In the FS, a local reference node would store the FS path (not the
URL!)
> of the target and (optionally) a revision number. If the rev number is
> absent, the path refers to HEAD. Conflict resolution for ref nodes is
> the same as for files.
>
Indeed, I'd point out here that a local reference node that's tied to a
revision number should be stored thusly:
TargetNodeID.TargetCopyID.TargetTxnID TargetPATH
TargetPATH is only for UI helping purposes, the use of a
TargetNodeID.TargetCopyID.TargetTxnID is a data retrieval optimization.
If you hadn't noticed this yet, this is the hard link that people have
been wanting. :) It even behaves sanely in the face of copies/branches.
> On the client side, some commands have to be aware of ref nodes, and
> there are usually two choices for the semantics: e.g., does "svn copy"
> copy the reference or the target? The simplest answer is to treat
> references like unix treats symlinks.
>
+1
> > One unanswered question is, how does a client create a
> > reference? Make a text file with the reference value in it,
and
> > then use a special flag at add time?
> >
> > $ svn add --reference foo
> >
> > Or overload symlinks? I dunno. There are probably multiple
> > acceptable solutions for the client-side user interface.
> >
> >
> You can't overload symlinks, because they aren't available everywhere.
> What you need is a new command:
>
> svn link [-r REVISION] TARGET SOURCE
>
> where both SOURCE and TARGET can be either a WC path or an URL (into
the
> same repository), and revision refers to TARGET, of course. If SOURCE
is
> an URL, this caises an implicit commit of the link. If SOURCE already
> exists and is a reference, this command would modify the reference
itself.
>
> There's also the question about how you remove a reference node. You
> have two choices:
>
> * "svn rm" on a reference always removes _just_ the reference, not
> the target
> * "svn unlink" removes only references; "svn rm" removes only
> targets, but requires --force
>
> I'm sort of leaning towards the first solution.
>
Let's continue the symbolic link metaphor, because that's what we indeed
have here. In that spirit the first solution definitely makes sense.
>
> Come to think of it, "svn link -r" would be sort of like a tag, too
...
>
More so than "svn copy /trunk/svn /tags/svn/milestone-X" is that's for
sure. In fact, I like this much better for doing tags. I don't suppose
this means anyone will let us rename "svn copy" to be "svn branch" now
that we can add a "svn tag TAGPATH -r SOURCEPATH" command. ;)
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 1957 - trunk/subversion/include trunk/subversion/libsvn_wc
Posted by Branko Čibej <br...@xbc.nu>.
I really meant to reply sooner ...
Karl Fogel wrote:
>Branko Čibej <br...@xbc.nu> writes:
>
>
>>-1
>>
>>
>
>Better have an alternate proposal, then :-).
>
Coming, coming ...
>I've just gone back and re-read those posts, so maybe I can put
>together a proposal that uses references now. This is totally off the
>top of my head -- I have *not* thought it through as much as I've
>thought through Jason's proposal in issue #517. I'm just taking your
>post as an opportunity to come up with a truly elegant module system,
>as opposed to a merely workable one. But if we can't get elegance in
>a reasonable amount of time, I think we should go with what's in #517.
>
>Definitions/requirements for a modules system:
>
> 1. A module is an alias, a single name that pulls together various
> sources to make a working copy tree. The sources may have
> specific revisions, or may be floating (i.e., at head).
>
> 2. Modules must be versioned.
>
> 3. Modules must be able to refer to sources in multiple
> repositories.
>
This would be a nice feature, but it's not a must for 1.0, and in fact
the client doesn't know how to handle working copies that refer to
multiple repositories (yet).
>Okay, two solutions:
>
> Solution A:
> ===========
> Modules come from description files.
> See issue #517 for details :-).
>
> Solution B:
> ===========
> Reference nodes.
>
>
>
[snip stuff about symlinks]
> The Subversion filesystem would support a new kind of node,
> called a `reference node'. A ref node is somewhat like a
> symlink, in that it stores text referencing some other source.
> That source might be local, might be in another repository
> entirely, might be a file, might be a dir... might even be a
> symlink! It's type might change from revision to revision (in
> the source repository, I mean -- the repository that contains
> the ref node doesn't know what type the target is).
>
> When you check out a tree containing reference nodes, each
> reference node is expanded into the appropriate entity. If
> subdir, then a subdir is created; if file, then a file is
> created, etc.
>
> The entry for the reference (i.e., in the .svn/entries file in
> the directory containing the reference) looks like a normal
> entry for whatever the target type is, but it has a few extra
> attributes (reference-url="http://..." and
> reference-target="http://..." and reference-target-rev="5" or
> somesuch), so that both the reference and its expansion can be
> versioned.
>
> A `module' is just a directory containing a bunch of references.
>
This is basically it, but I'll expand a bit. I think we'd need two kinds
of references -- local (intra-repository) and global (inter-repository).
Whether those are implemented using the same node type isn't important
now. Global refs aren't necessary for 1.0, and are a huge problem by
themselves, so I'll ignore them.
In the FS, a local reference node would store the FS path (not the URL!)
of the target and (optionally) a revision number. If the rev number is
absent, the path refers to HEAD. Conflict resolution for ref nodes is
the same as for files.
On the client side, some commands have to be aware of ref nodes, and
there are usually two choices for the semantics: e.g., does "svn copy"
copy the reference or the target? The simplest answer is to treat
references like unix treats symlinks.
> One unanswered question is, how does a client create a
> reference? Make a text file with the reference value in it, and
> then use a special flag at add time?
>
> $ svn add --reference foo
>
> Or overload symlinks? I dunno. There are probably multiple
> acceptable solutions for the client-side user interface.
>
>
You can't overload symlinks, because they aren't available everywhere.
What you need is a new command:
svn link [-r REVISION] TARGET SOURCE
where both SOURCE and TARGET can be either a WC path or an URL (into the
same repository), and revision refers to TARGET, of course. If SOURCE is
an URL, this caises an implicit commit of the link. If SOURCE already
exists and is a reference, this command would modify the reference itself.
There's also the question about how you remove a reference node. You
have two choices:
* "svn rm" on a reference always removes _just_ the reference, not
the target
* "svn unlink" removes only references; "svn rm" removes only
targets, but requires --force
I'm sort of leaning towards the first solution.
Come to think of it, "svn link -r" would be sort of like a tag, too ...
--
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: svn commit: rev 1957 - trunk/subversion/include trunk/subversion/libsvn_wc
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Branko Čibej <br...@xbc.nu> writes:
> Just a minute. Are you doing all this work /instead/ of adding
> reference nodes to the filesystem? And this will all get ripped out
> once we have reference nodes? Sorry, but I don't like that at all.
Well, not doing all this work if there's a better way :-). I was
never particularly entranced with this method, though I admired its
economy of effort :-). Mainly I just couldn't see a better one,
because I didn't understand any of the reference node proposals (or
rather, I didn't understand how they would solve the modules problem).
> I also didn't find any design doc for this feature, discussing pros
> and cons and tradeoffs vs. reference nodes. I only remember one or two
> posts to the dev list, without any real conclusions.
>
> (Can you point me to the relevant messages if I missed them? Thanks.)
The design doc for these recent commits is in issue #517. There were
a lot of posts to the dev list, mainly about using references --
search for subject "svn modules". The discussion was inconclusive,
yeah.
If I understood *exactly* what you mean by "adding reference nodes to
the filesystem", and how it solves the modules problem, I'd be able to
answer yes or no to your original question. Part of the problem with
the reference-based proposals was that they were light on concrete
details. A general idea would be presented, but then there was a fair
amount of handwaving. The proposal in issue #517 is detailed, and is
known to solve the problem.
If we *can* do this with reference nodes, great! It would be more
"along the grain" of Subversion, rather than against, so to speak.
> -1
Better have an alternate proposal, then :-).
I've just gone back and re-read those posts, so maybe I can put
together a proposal that uses references now. This is totally off the
top of my head -- I have *not* thought it through as much as I've
thought through Jason's proposal in issue #517. I'm just taking your
post as an opportunity to come up with a truly elegant module system,
as opposed to a merely workable one. But if we can't get elegance in
a reasonable amount of time, I think we should go with what's in #517.
Definitions/requirements for a modules system:
1. A module is an alias, a single name that pulls together various
sources to make a working copy tree. The sources may have
specific revisions, or may be floating (i.e., at head).
2. Modules must be versioned.
3. Modules must be able to refer to sources in multiple
repositories.
Okay, two solutions:
Solution A:
===========
Modules come from description files.
See issue #517 for details :-).
Solution B:
===========
Reference nodes.
First, note that ref nodes are different from symlinks. Making
Subversion support symlinks is pretty simple:
$ ln "../foo" bar
$ ln "my cat's breath smells like cat food" baz
$ ln "http://svn.collab.net/repos/svn/blah/blah" qux
$ svn add bar baz qux
$ svn ci -m "Added three symlinks." bar baz qux
Subversion does not pay attention to the value (target) of a
symlink. The values get updated if someone committed changes to
them, but Subversion doesn't *interpret* the values in any way.
Okay, now that we've cleared up *that* potential confusion... :-)
The Subversion filesystem would support a new kind of node,
called a `reference node'. A ref node is somewhat like a
symlink, in that it stores text referencing some other source.
That source might be local, might be in another repository
entirely, might be a file, might be a dir... might even be a
symlink! It's type might change from revision to revision (in
the source repository, I mean -- the repository that contains
the ref node doesn't know what type the target is).
When you check out a tree containing reference nodes, each
reference node is expanded into the appropriate entity. If
subdir, then a subdir is created; if file, then a file is
created, etc.
The entry for the reference (i.e., in the .svn/entries file in
the directory containing the reference) looks like a normal
entry for whatever the target type is, but it has a few extra
attributes (reference-url="http://..." and
reference-target="http://..." and reference-target-rev="5" or
somesuch), so that both the reference and its expansion can be
versioned.
A `module' is just a directory containing a bunch of references.
One unanswered question is, how does a client create a
reference? Make a text file with the reference value in it, and
then use a special flag at add time?
$ svn add --reference foo
Or overload symlinks? I dunno. There are probably multiple
acceptable solutions for the client-side user interface.
Anyway, is this something like what you had in mind?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org