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

Re: New idea for the checkout process

From: BRM <bm_witness_at_yahoo.com>
Date: Wed, 10 Jun 2009 10:26:03 -0700 (PDT)

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.

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.)

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.


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.

From: Robert Dailey <rcdailey_at_gmail.com>
To: dev_at_tortoisesvn.tigris.org
Sent: Wednesday, June 10, 2009 9:35:10 AM
Subject: Re: New idea for the checkout process

On Wed, Jun 10, 2009 at 6:11 AM, Hans-Emil Skogh <Hans-Emil.Skogh_at_tritech.se> wrote:

>I agree. The suggestion looks very nice to improve the usability of sparse checkouts, but the question is if it would be worth the work...

Well the question of whether it is worth the work or not doesn't really come down to if the feature would be practical or not, it basically comes down to who we can get to work on it. However, I think both facts intertwine to some degree.
I tend to consider reorganising my repository when I find myself in a situation where I would like to exclude some parts of a working copy. With a good repository layout, the need to use sparse checkouts can be almost completely eliminated.

You're wrong. There is no single definition for a "good repository layout". It is highly subjective and use-case specific. Only the project or company can determine what the right repository layout is for their needs, and that particular layout may not be useful to other people. I've seen cases where externals were the most useful path, and other cases where sparse directory support were required and frequently used.

Determining if this feature is worth the effort is going to be nearly impossible for these reasons.

A good example of what I'm talking about is a repository that must consider multiple projects that share a single common code base, for example, an engine of some sort. Normally the most ideal solution to this kind of structure is to use externals (This was required in pre-svn 1.5 days) or sparse checkouts. Without using these features, you would be required to "duplicate" the "engine" in the repository itself, which is undesirable.


To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-06-10 19:26:12 CEST

This is an archived mail posted to the TortoiseSVN Dev mailing list.

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