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 <brane@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
Received on Thu Apr 27 11:10:09 2006