Re: New idea for the checkout process

Needless to say per the sparse checkout - I am agreeing with you that it is still a necessary feature as it solves the problem as some people will require it. Per #1 below, you can't necessarily reorganize your repository becomes one projects needs to use a sparse checkout. Someone else, that plainly doesn't care, might be the administrator.

Now...as to my scripting example -

My script does the following:
1) manages the dependencies for a project
2) builds the project (using Visual Studios)

In the case of managing dependencies, yes - it checks stuff out on its own directory (e.g. <project>\dependency_tree\<dependency>) using the command-line client, creating a clear line between what is in a dependency and what is in the main project. It will also detect whether a change in the dependency file occurs and remove/checkout to keep in sync, and update the dependencies. It is also designed to hook into the main project's build tool (via the pre-build scripting in Visual Studios). Additionally, it provides a limited intelligent removal - that is, it'll clear out a dependency unless you've made a change, in which case, it'll prompt you about whether or not you want to actually remove it.

Now, why might I prefer this method over svn:externals?

First, it's also part of the tool chain during the build and builds all the dependencies for me.
Second, it's far more visible that a change was made.
Third, it's far easier to use. TSVN provides a great interface under Windows; but I have had a lot of trouble trying to get them to work under the command-line client - which I also use rather regularly.

I reviewed the docs on svn properties, and they are a bit more flexible than I originally thought, but I still think this provides the better solution, at least for the projects using it. I do have another project using svn:externals, but haven't decided yet whether it will continue to do so or whether it will get converted to using a script to manage the dependency; I had originally used in in hopes that I would be able to more easily integrate it into the QMake build system, but that hasn't worked yet either, so I am left to building the dependencies by hand, before the project under Linux (for now).

Ben

________________________________
From: Robert Dailey <rcdailey_at_gmail.com>
To: dev_at_tortoisesvn.tigris.org
Sent: Wednesday, June 10, 2009 2:36:51 PM
Subject: Re: New idea for the checkout process

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=2361081

To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-06-10 23:25:11 CEST