RQ: svn:cat property

[Flex <fl...@datecs.bg>]

Hi gang,


While waiting for
http://subversion.tigris.org/issues/show_bug.cgi?id=823

which may take veeery long time can you do something instead...
The problem that requires single file externals (an example):

Library:
--Source1.c
--Source2.c
--Source3.c
--...
--Library.h

App:
--Source1.c

In this case Library is some closed source lib, while the App is the example sent to the users. This example needs Library.h. So making svn:externals to the whole library is not an option, and rearranging some of the files in the Library project is sometimes impossible, sometimes not desirable.

There is now a "workaround" for this - svn cat but it is weak workaround. I'm not speaking of the files get are not versioned, but the the fact that you have to manually do x times "svn cat" after checkout to get the project fully operational. In the case of a single project with single developer... well this may work, but if some colleague has to check out the project he'll end up with missing files. And if there are lot of projects...

I'm asking for second workaround, something that will probably be made with ease - adding svn:cat as a folder property, just like the svn:externals but for single files. So the project will be checked out with ease. There is only one limitation to this way - files are not versioned but this will not change until 823 and I can live with that.

Re[2]: RQ: svn:cat property

[Flex <fl...@datecs.bg>]

>> I'm asking for second workaround, something that will probably be made
>> with ease - adding svn:cat as a folder property, just like the
>> svn:externals but for single files. So the project will be checked out
>> with ease. There is only one limitation to this way - files are not
>> versioned but this will not change until 823 and I can live with that.

> I understand the request, but I personally would be opposed to adding
> such a workaround feature, since we'd have to support it forever, even
> after the deficiency that made it necessary has long been fixed.

> Other developers might feel differently; I'm speaking only for myself.

True :)
However svn will never stop supporting "svn cat" for compatibility and this workaround is just a call to it... i.e. it is so simple (or looks like) that it'll not require any attention at all and will work "by itself" until svn cat is alive. Currently those needed to checkout a single file are doing it the "manual" way:
svn co
svn cat

This is just a merged operation and nothing new at all.
Thinking about the "real" checkout a single file with the current smaller unit be a folder will be horrible to implement and I'm going to doubt we'll see it anytime soon.

Re: RQ: svn:cat property

[kf...@collab.net]

Flex <fl...@datecs.bg> writes:

> Hi gang,
> 
> 
> While waiting for
> http://subversion.tigris.org/issues/show_bug.cgi?id=823
> 
> which may take veeery long time can you do something instead...  The
> problem that requires single file externals (an example):
> 
> Library: --Source1.c --Source2.c --Source3.c --...  --Library.h
> 
> App: --Source1.c
> 
> In this case Library is some closed source lib, while the App is the
> example sent to the users. This example needs Library.h. So making
> svn:externals to the whole library is not an option, and rearranging
> some of the files in the Library project is sometimes impossible,
> sometimes not desirable.
> 
> There is now a "workaround" for this - svn cat but it is weak
> workaround. I'm not speaking of the files get are not versioned, but
> the the fact that you have to manually do x times "svn cat" after
> checkout to get the project fully operational. In the case of a single
> project with single developer... well this may work, but if some
> colleague has to check out the project he'll end up with missing
> files. And if there are lot of projects...
> 
> I'm asking for second workaround, something that will probably be made
> with ease - adding svn:cat as a folder property, just like the
> svn:externals but for single files. So the project will be checked out
> with ease. There is only one limitation to this way - files are not
> versioned but this will not change until 823 and I can live with that.

I understand the request, but I personally would be opposed to adding
such a workaround feature, since we'd have to support it forever, even
after the deficiency that made it necessary has long been fixed.

Other developers might feel differently; I'm speaking only for myself.

Best,
-Karl

-- 
www.collab.net  <>  CollabNet  |  Distributed Development On Demand

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org