[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: vote: checkout a single file - vs - checkout everything EXCEPT a single file

From: Vincent Starre <vstarre_at_comcast.net>
Date: 2005-08-18 14:01:09 CEST

But really this seems to miss the point. Really, svn:externals should be
able to work on files, not just directories, shouldnt they?
I have a similar situation, though reversed- I've got several files
while should really only be checked out on one operating system.
I was thinking this should be tied in to svn:externals, but rather than
adding an extra directory, it would be only a partial checkout.
Please note, to those who dont understand: breaking up the directory
structure is sometimes a bad thing. (not always, and in the
case of libraries, breaking up into a seperate dir really does make
sense, though seperating the one library you need from all the
others really does not make sense)
I was thinking along the lines of creating "linked copies". That is, a
copy of another directory which actually acts on the original
directory, except with removes (which would need a new "rmlink" or some
such command)

Just looking at the proccess gone through-
    - check out a dir
    - rm (not svn rm) the files I dont want
    - work work work
    - nothing bad happens.
    - If I update, I get the old files back

Support for having those files not get re-downloaded each time would be
nice, and is pretty much all that's required.
This could help your situation as well, as you'd be able to create a
linked copy with only the files you want, and use svn:externals
to grab that copy into a lib directory.
Ideally, one would be able to do things such as
    - link to files from arbitrary directories
    - link entire directories only "excluding" certain files, so adds
would also be linked in
    - rename files and have those changes show up in both copies
    - show the log messages from both copies
    - rename files and have those changes only show up in one copy

The basic idea is: "I only have this one file different between these
two- should I really be required to branch and merge everything,
rather than treating everything besides this one file as being the same?"

But hey, it's just a thought. Based on response from #svn, no version
control system current supports such a thing and
therefor it's a completely stupid idea which would be useful to no one.

Phillip Susi wrote:

> I'm not sure what you mean by single file checkout, but the problem
> you describe seems to have a simple solution to me.
> Organize your library project so that the source is in one directory
> and the headers and objects go into another directory. Use the
> svn:external attribute to 'attach' the library object and header
> directory to the projects that depend on it. Then when you do a
> checkout on the other projects, you'll get the library with them. If
> you want the source code to the library, you explicitly check out the
> source directory, which presumably you would configure your server to
> limit access to.
> Flex wrote:
>> You are going to shoot me right? :)
>> Don't... at least not now :) I know this has been posted many MANY
>> times, I know the answers too, but I haven't found an answer: "Why?"
>> I have finally decided to move to a source control system and have
>> done a heavy research. Years of work, lot of projects had to be
>> cleaned and better managed. I have tried a lot of systems and have to
>> admit - subversion is the absolute winner... until I moved the first
>> project to the repository and tried to "attach" a file from another
>> project to it. An I was unable to do.
>> It was about just a huge library, lot of sources and about 10 or so
>> projects using this library - they only needed updated headers and the
>> object, nothing more so if I externally attached the whole library
>> source folder that results in a mess in the projects using it and on
>> top of that - some of the projects were "example" ones - built for the
>> customers which were not supposed to receive the library source too.
>> Taking into consideration how much similar libraries I have, how much
>> "util" files I have that are used in different projects I started
>> examining the docs very deep. My colleagues were using VSS but they
>> have followed the research since they wanted to move too. However when
>> I told them that SVN does not support single file checkout the answer
>> was "It can't be true, I haven't heard of such a system not supporting
>> that, even the VSS has it, so check out the docs, you have mistaken
>> something." I whish I had. While keep telling to myself that I have to
>> be in some kind of a huge mistake I went to the mailing lists archive
>> and have done a search. 2290 results. The same question and the same
>> answers. Read 3 pages before giving up. Hard to believe but that
>> feature is really missing.
>> So after some discussion we decided to move away from SVN and go to
>> CVS since it does support it. However SVN is far ahead, it's just the
>> perfect system with just one huge problem, I don't want to move away
>> so I checked the bug reports and found it:
>> http://subversion.tigris.org/issues/show_bug.cgi?id=823
>> I'm just going to ask everyone from these 2290 or I don't know how
>> much who have seen that, read a bit and just walked away - to vote for
>> checkout single file to be added:
>> http://subversion.tigris.org/issues/showvotes.cgi?voteon=823
>> Thanks for your patience to read all this especially with my horrible
>> English knowledge :)
>> Have a nice day
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: users-help@subversion.tigris.org

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 18 14:03:24 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.