You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Madan U Sreenivasan <ma...@collab.net> on 2006/04/25 06:59:44 UTC
[PROPOSAL] Issue 823 - svn checkout a single file
Hi,
Pl. find attached my proposal for fixing Issue 823. I have also
attached this proposal to the issue
(http://subversion.tigris.org/nonav/issues/showattachment.cgi/559/823.proposal.txt).
Am writing here, as per Sussman's suggestion.
Again, as I said in the issue : I understand the possibilities of
solving issue 823, without the wc format changes that are proposed in the
attached document. However, I wanted to highlight the idea, to get a
discussion going. We could optimize the changes as we discuss here.
This is a relatively simple proposal, and I would like all of you to
participate. Thanks all in advance!
Regards,
Madan.
Re: [PROPOSAL] Issue 823 - svn checkout a single file
Posted by Julian Foad <ju...@btopenworld.com>.
Madan U Sreenivasan wrote:
> - Checkout such single files from multiple repositories into the same
> directory (implicitly, allow further svn operations on those files)
How does this proposal relate to each of the following?
* "Externals".
* Non-recursive check-out.
* "svn switch".
This proposal talks mainly about a "file". Does it also cover checking out a
single subdirectory from an arbitrary location, having it integrated into the
current directory in the same sense that a single file is? (That is, "svn
status" would not show "?" as the status of the sub-directory.)
What semantics would we expect or require with regard to some files in a
directory being checked out from locations different from the others? For
example, what commands would be allowed to operate on a set of items checked
out from multiple locations?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL] Issue 823 - svn checkout a single file
Posted by Alan Barrett <ap...@cequrux.com>.
On Tue, 25 Apr 2006, Madan U Sreenivasan wrote:
> Achieve the following:
>
> - Checkout single file from a repository (implicitly, allow further
> svn operations on that file)
>
> - Checkout such single files from multiple repositories into the same
> directory (implicitly, allow further svn operations on those files)
>
> - Design such a way that the problems related to non-recursive
> checkouts (http://subversion.tigris.org/issues/show_bug.cgi?id=695)
> would be easier to handle.
Am I right in thinking that this would have the natural effect of also
allowing "svn switch" of single files, and allowing svn:externals to
point to single files?
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL] Issue 823 - svn checkout a single file
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 4/26/06, Ben Collins-Sussman <su...@red-bean.com> wrote:
> And now a counter-proposal...
>
> Ben Reser (before he vanished) spent a lot of time designing and
> coding a solution to issue #695 -- to allow true 'nonrecursive'
> checkouts.
>
> The general solution he was working on was a way for users to specify
> that they "wanted" or "didn't want" certain files and dirs. We
> currently have a .svn/entries attribute which means, "I want this
> thing, but the server says I'm not authorized to have it.". But Ben
> was working on a flag which means "I don't want this, don't give it to
> me." It was a change to both client and server logic, and also
> involved designing a new UI to trigger this feature.
>
> The reason I bring this up is because a single-file checkout is just a
> sub-case of this larger feature. The task is currently listed as
> something for a Summer of Code student to work on (on our tasks page:
> http://subversion.tigris.org/project_tasks.html), but if Madan wants
> to start working on it earlier, that would be neat too. The trick is
> to resurrect Ben's notes and design and patch-in-progress, and
> continue the work...
Personally, I agree, we already have a perfectly reasonable design for
this sort of feature, it seems far more productive to continue that
work than to start a new design from scratch.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL] Issue 823 - svn checkout a single file
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 4/27/06, Madan U Sreenivasan <ma...@collab.net> wrote:
> hmmm..... I think that there shouldnt be an entry for a file that doesnt
> exist in the current wc.
That would mean that the .svn/entries file is incomplete. And when
the entries file is incomplete, then 'svn up' takes much longer ...
it has to resort to CVS-style update reporting. Instead of saying to
the server, "I have revision 2349 of this directory", it has to say,
"I have revision 2349 of this directory, but I don't know if my list
of children is complete; so here's a list of every child that I have:
A, B, C, D..." Very inefficient.
Why wouldn't you want the entries file to be complete and
knowledgeable all the time? The entries file isn't supposed to be a
*literal* reflection of the directory, but rather the central
storehouse for all metadata about the directory: and some of that
metadata simply reflects which children are actually present or not,
or wanted by the user or not. I would argue that such metadata is
better represented as a flag (or set of flags), rather than removal of
the entire entry! If the whole entry is missing, you have less
control over the situation, and have crippled your ability to talk to
the server.
> designing a new UI? you mean adding of a new
> option/suboptions, right?
Yeah, some UI that allows the user to say, "make this child go away, I
don't want it", or "make this child come back again".
>
> I agree.... but not something dependant on the larger issue to get
> fixed... in fact, fixing this might pave the way to solve the 'svn co -N'
> simpler... dont you think so?
I think it's the other way around! If you implement 'svn co -N' and a
UI to say "give me this one child", then you're done. That's exactly
the procedure to get a single file checkout.
>
> > The task is currently listed as
> > something for a Summer of Code student to work on (on our tasks page:
> > http://subversion.tigris.org/project_tasks.html), but if Madan wants
> > to start working on it earlier, that would be neat too.
>
> Yes, I want to work on this... I earlier thought the change would be
> localized to libsvn_wc.... looking at the code, am now thinking - it
> wouldnt be...
Nope, it would probably require network and server changes too.
>
> > The trick is
> > to resurrect Ben's notes and design and patch-in-progress, and
> > continue the work...
>
> yep.... could you help me out with this pl.
>
Try searching for the most recent emails from Ben Reser.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL] Issue 823 - svn checkout a single file
Posted by Madan U Sreenivasan <ma...@collab.net>.
On Wed, 26 Apr 2006 18:24:23 +0530, Ben Collins-Sussman
<su...@red-bean.com> wrote:
> And now a counter-proposal...
>
> Ben Reser (before he vanished) spent a lot of time designing and
> coding a solution to issue #695 -- to allow true 'nonrecursive'
> checkouts.
>
> The general solution he was working on was a way for users to specify
> that they "wanted" or "didn't want" certain files and dirs. We
> currently have a .svn/entries attribute which means, "I want this
> thing, but the server says I'm not authorized to have it.". But Ben
> was working on a flag which means "I don't want this, don't give it to
> me." It was a change to both client and server logic, and also
> involved designing a new UI to trigger this feature.
hmmm..... I think that there shouldnt be an entry for a file that doesnt
exist in the current wc. designing a new UI? you mean adding of a new
option/suboptions, right? If so, I need some time to get it done... am
looking at the feasibility of getting this out at the code level with
minimal changes...
btw, is there any record of his work that I could refer to? (apart from
the mailing list/issue tracker)
>
> The reason I bring this up is because a single-file checkout is just a
> sub-case of this larger feature.
I agree.... but not something dependant on the larger issue to get
fixed... in fact, fixing this might pave the way to solve the 'svn co -N'
simpler... dont you think so?
> The task is currently listed as
> something for a Summer of Code student to work on (on our tasks page:
> http://subversion.tigris.org/project_tasks.html), but if Madan wants
> to start working on it earlier, that would be neat too.
Yes, I want to work on this... I earlier thought the change would be
localized to libsvn_wc.... looking at the code, am now thinking - it
wouldnt be...
> The trick is
> to resurrect Ben's notes and design and patch-in-progress, and
> continue the work...
yep.... could you help me out with this pl.
Thanks and Regards,
Madan.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL] Issue 823 - svn checkout a single file
Posted by Ben Collins-Sussman <su...@red-bean.com>.
And now a counter-proposal...
Ben Reser (before he vanished) spent a lot of time designing and
coding a solution to issue #695 -- to allow true 'nonrecursive'
checkouts.
The general solution he was working on was a way for users to specify
that they "wanted" or "didn't want" certain files and dirs. We
currently have a .svn/entries attribute which means, "I want this
thing, but the server says I'm not authorized to have it.". But Ben
was working on a flag which means "I don't want this, don't give it to
me." It was a change to both client and server logic, and also
involved designing a new UI to trigger this feature.
The reason I bring this up is because a single-file checkout is just a
sub-case of this larger feature. The task is currently listed as
something for a Summer of Code student to work on (on our tasks page:
http://subversion.tigris.org/project_tasks.html), but if Madan wants
to start working on it earlier, that would be neat too. The trick is
to resurrect Ben's notes and design and patch-in-progress, and
continue the work...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL] Issue 823 - svn checkout a single file
Posted by Madan U Sreenivasan <ma...@collab.net>.
As I indicated earlier, I know that we can do without the extra parameter
'type' Anyways, I didnt know about the individual entry url/repos
overriding the 'this_dir' entry.. cool... am learning the code now...
thanks for the pointer....
Now that am reading it... I need to see the feasibility for acheiving this
with least code/design changes... give me some time... will get back to
you on this... thanks for the feedback.
Regards,
Madan.
On Wed, 26 Apr 2006 17:38:55 +0530, Branko Čibej <br...@xbc.nu> wrote:
> Madan U Sreenivasan wrote:
>> Proposed Changes to the .svn/entries file:
>> ------------------------------------------
>>
>> The following attributes should be made optionally available for entries
>> of `kind=file'
>>
>> - url : This enables the singularly checked-out file to be tracked
>> against its repository of origin.
>>
> This has been possible since forever. This is exactly what "svn switch"
> of a single file does.
>
>> - repos : This enables the singularly checked-out file to be
>> tracked against its repository of origin.
>>
> Given the way the entries parser works, this should also be already
> possible. I don't know about the new parser.
>
>> In addition, we also require the following optional attribute for
>> entries of `kind=file'
>>
>> - type : This is optional, and currently only the following value
>> can be held here...
>>
>> `singular' - which implies that the entry corresponds to a
>> singularly checked-out file, and that the entry
>> itself is complete (with url and repos attributes)
>> enough to be associated with a file in a repository.
>>
>> If `type=singular' is absent, it means that this entry is
>> dependant on the `this-dir' entry for completeness.
>>
> Why should this new attribute be necessary? IN the entries file,
> Per-entry attributes override per-this_dir attributes. entry->repos can
> be different from this_dir->repos (and more important, entry->uuid can
> be different from this_dir->uuid).
>
> "svn status" will already show such files as switched (with an S, hehe).
> All you have to worry about is to not allow a single-file switch outside
> that single file's repository.
>
>> How requirements are met:
>> -------------------------
>>
>> This section illustrates how the 4 points presented in `Analysis'
>> section are achieved.
>>
>> For convenience, lets call an entry with `kind=file' and
>> `type=singular', as a `singular_file' entry. This entry must have the
>> `url' and `repos' attributes too.
>>
>> (1) Can be achieved by having a .svn/entries file with one `this_dir'
>> entry, and no `singular-file' entry.
>>
>> (2) Can be achieved by having a .svn/entries file with no `this_dir'
>> entry, and exactly one `singular-file' entry.
>>
>> (3) Can be achieved by having a .svn/entries file with no `this_dir'
>> entry, and one or more `singular-file' entries.
>>
>> (4) Can be achieved by having a .svn/entries file with one `this_dir'
>> entry, and one or more `singular-file' entries. The `this_dir'
>> entry corresponds to the first `svn co' ed directory. Subsequent
>> checkouts of complete dirs into the same working copy directory,
>> would be rejected with the message: `svn: 'wc' is already a
>> working copy for a different URL'.
>>
> See? In cases 1, 2 and 3, type=singular is redundant. In case 4, it's
> not necessary. And I'd strongly suggest _not_ supporting singular-file
> checkouts combined with a this_dir that's in the same repository. We
> already have that functionality, and it's called "svn switch".
>
>
> Now, I'd be more interested in the user interface for such a feature.
>
> -- Brane
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL] Issue 823 - svn checkout a single file
Posted by Branko Čibej <br...@xbc.nu>.
Madan U Sreenivasan wrote:
> Proposed Changes to the .svn/entries file:
> ------------------------------------------
>
> The following attributes should be made optionally available for entries
> of `kind=file'
>
> - url : This enables the singularly checked-out file to be tracked
> against its repository of origin.
>
This has been possible since forever. This is exactly what "svn switch"
of a single file does.
> - repos : This enables the singularly checked-out file to be
> tracked against its repository of origin.
>
Given the way the entries parser works, this should also be already
possible. I don't know about the new parser.
> In addition, we also require the following optional attribute for
> entries of `kind=file'
>
> - type : This is optional, and currently only the following value
> can be held here...
>
> `singular' - which implies that the entry corresponds to a
> singularly checked-out file, and that the entry
> itself is complete (with url and repos attributes)
> enough to be associated with a file in a repository.
>
> If `type=singular' is absent, it means that this entry is
> dependant on the `this-dir' entry for completeness.
>
Why should this new attribute be necessary? IN the entries file,
Per-entry attributes override per-this_dir attributes. entry->repos can
be different from this_dir->repos (and more important, entry->uuid can
be different from this_dir->uuid).
"svn status" will already show such files as switched (with an S, hehe).
All you have to worry about is to not allow a single-file switch outside
that single file's repository.
> How requirements are met:
> -------------------------
>
> This section illustrates how the 4 points presented in `Analysis'
> section are achieved.
>
> For convenience, lets call an entry with `kind=file' and
> `type=singular', as a `singular_file' entry. This entry must have the
> `url' and `repos' attributes too.
>
> (1) Can be achieved by having a .svn/entries file with one `this_dir'
> entry, and no `singular-file' entry.
>
> (2) Can be achieved by having a .svn/entries file with no `this_dir'
> entry, and exactly one `singular-file' entry.
>
> (3) Can be achieved by having a .svn/entries file with no `this_dir'
> entry, and one or more `singular-file' entries.
>
> (4) Can be achieved by having a .svn/entries file with one `this_dir'
> entry, and one or more `singular-file' entries. The `this_dir'
> entry corresponds to the first `svn co' ed directory. Subsequent
> checkouts of complete dirs into the same working copy directory,
> would be rejected with the message: `svn: 'wc' is already a
> working copy for a different URL'.
>
See? In cases 1, 2 and 3, type=singular is redundant. In case 4, it's
not necessary. And I'd strongly suggest _not_ supporting singular-file
checkouts combined with a this_dir that's in the same repository. We
already have that functionality, and it's called "svn switch".
Now, I'd be more interested in the user interface for such a feature.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org