On Wed, Jun 10, 2009 at 12:26 PM, BRM <bm_witness_at_yahoo.com> wrote:
> Two comments:
>
> 1) I believe the comment about 'good repository layout' is basically saying
> that if they needed sparse checkout, chances are they could do better by
> reorganizing the repository instead and get the same desired result. I'll
> that that may be the case for 99% of the cases for sparse checkout, but not
> for 100% of them so having support for sparse checkout is certainly a good
> thing.
I know exactly what it was saying, and as you have reworded it I still
disagree with it. This isn't something statistical, so saying 99% isn't even
remotely accurate. The example I gave before about multiple projects sharing
a common code base without duplicating repository data proves this point. A
lot of people put multiple projects in the same repository, and normally all
projects use a common code base like an "Engine" (for games) or some
framework for GUI apps, as a few more examples.
Again, I think that trying to justify not implementing this feature based on
supposed "statistics" or "It can always be done differently..." isn't going
to work. These are not logical reasons.
2) You missed another use-case alternative to sparse checkout - scripting.
> And it can be done on both Windows and Linux/Mac/Unix/etc.
>
> I presently have a set of projects that utilize a lot of common code. I'm
> not a fan of svn:externals as I don't see them as being quite flexible
> enough - for example, I like being able to change a dependency without
> affecting the repository. Don't get me wrong - they're great, but don't
> solve 100% of the problem. So I setup a script that knows a little bit about
> my repository (e.g. the layout for projects its concerned with), and each
> project that needs access to those dependencies is then enabled with the
> script, which checks a file for the list of dependencies that it knows how
> to find, and then pulls them into a specific directory and builds them. In
> my case here, it's helpful to be able to work on a project and change a
> dependency without changing what someone else working on the same branch
> might use. (Now I might be missing something per svn:externals...and if so,
> please do correct me.)
I don't see how scripting is providing you any benefit here. Scripting, to
me, sounds like a poor replacement for externals. At least with externals,
subversion can recognize them and update them recursively. With a script,
the best you can do is multiple checkouts, each of which would require an
entirely new update operation, which makes them even more tedious and
impractical.
If I am missing something, please do elaborate a bit more. You didn't quite
go into details about how the script obtains your dependencies, nor how it
affects your ability to do updates. It seems like that in order to make this
even remotely useful, the script would have to be used for ALL operations
(e.g. updates, commits, checkouts). And if this is the case, you've
arbitrarily limited what the user can do to their working copy in a
convenient way.
Let's not even get into how this complicates branching.
Also, why would you want to change a dependency without changing the
repository? If a particular project in version control absolutely cannot
function without an additional part of the repository, then it makes perfect
sense to handle that dependency at the lowest level possible to avoid
redundant efforts. For example, in your case, each client would be required
to ensure that those dependencies are maintained locally (Regardless of if a
script is used or not, it still must be done manually to some extent).
Whereas I could, instead, just do a single checkout and be done and all of
my dependencies are handled.
In fact, externals are actually the best solution for managing dependencies,
because they require the least amount of interaction when being used (i.e.
updates, checkouts).
If dependencies are not static, then you should not be relying on the
version control system to handle that for you. This could be better handled
with your build system / IDE. The version control system's responsibility is
to make sure your working copy is 100% complete, and that means having every
possible dependency you will need based on certain preconditions, such as
your platform, compiler, or project.
Sure, sparse checkout might help, as might svn:externals. But it doesn't
> solve the entire problem; and in some cases scripting can solve the
> remainder of the problem - but not in a general way that can be part of a
> tool chain like TSVN/SVN - it'll be specific to the user's use-case.
In general, you will never get a perfect repository. In my experience it has
always been about compromise. I've done the hard work of experimenting with
all of my options and I've come to respect that there is no "Golden Hammer"
in Subversion, you literally have to design, analyze, compromise, and adapt
your repository for each project.
My feature request here adds one more useful tool to use during that
process. It helps, amongst other things, to promote a specific feature's
practice. I can tell you right now that I know a lot of people that would be
more motivated to use sparse checkouts if there actually were an interface
for it.
Additionally, a lot of people don't even know about sparse checkouts because
of the lack of an interface. Right now to get a sparse checkout you have to
go through what seems to be several "back doors". TortoiseSVN has been
lacking a true interface for sparse directories since its conception in SVN
1.5. And for such a wonderful feature, I expect more from TSVN.
P.S. FWIW, I've found that it is far easier to manipulate svn:externals with
> TSVN than the SVN command-line client, which I still haven't gotten them to
> work on.
Right, because unlike SVN, TSVN actually has an intuitive interface. In this
day and age I can't believe we're still so dependent on command line
interfaces. Anyway, this is a topic for another day :)
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2361040
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-06-10 20:37:00 CEST