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

RE: Philosophical question: Tagging & Structure

From: Johan Corveleyn <johan.corveleyn_at_uz.kuleuven.ac.be>
Date: Fri, 3 Jul 2009 14:36:11 +0200

> -----Oorspronkelijk bericht-----
> Van: Robert Dailey [mailto:rcdailey_at_gmail.com]
[snip]
> 2. Sparse Checkouts. We can keep all projects and dependencies
> in the repository in one "flat" structure. In other words, at the
> root of the repository we would have Project1, Library1, Library2,
> and any other projects or other libraries. When we do a checkout
> and we only want Project1 and its dependencies, we rely on checkout
> depth to choose only the parts of the repository we want. This
> would not have been possible in pre-1.5 builds of subversion.
[snip]
> Technique #2:
>
> * I can't just tag Project1 and its dependencies in this case.
> If there exists a Project2 and a Project3, neither of which I am
> working on or intend to tag, those will show up in the tag
> regardless. This complicates the tags.
> * I am not aware of how this technique will work if I'm using a
> client at version 1.6 and a server at 1.4. I've had issues of
> updates grabbing over a gigabyte of data (With no status
> information being output to the user) when I do an update from a
> directory with sparse checkouts. I expect anomalies and weird
> behavior to happen in this case.
> * It's harder to tell people how to do checkouts. If a new
> programmer joins my team, I can't just send him a repository URL
> and tell him to check that out. I have to tell him HOW to use
> sparse checkouts (If he's not familiar with them) and also tell him
> which parts of the repository to explicitly grab.
> * Dependencies are not automatically managed (This also plays a
> big part in the previous point). You can forget to grab
> dependencies and you may not find out till much later. This is
> error prone.

I haven't done this myself, but you could also do a variation of #2, namely "Sparse branching/tagging". Branching/tagging on the server that is, not through a (sparse) working copy.

You can do this, because "svn cp" takes multiple source arguments (which I recently found out). So, suppose you have the flat structure you talk about in technique #2, you could do the following:
$ svn cp <url>/trunk/Project1 <url>/trunk/Library1 <url>/trunk/Library2 <url>/tags/Project1/release1.0

Or for Project2 (say depending only on Library2):
$ svn cp <url>/trunk/Project2 <url>/trunk/Library2 <url>/tags/Project2/release1.0

That would perform a server-side copy of a list of urls, to a target directory (branch or tag). No need to have specific working copies to do that.

Of course you could create a very simple script to do that, using small config files listing each Project's dependencies or something like that.

Note: you may have to create the tag directory (Project1/release1.0) first, I think it has to exist for the above command to work (I'm not sure, you'll have to try). If you want to create that directory and do the moves in one single commit, maybe you should have a look at svnmucc: http://subversion.tigris.org/tools_contrib.html#svnmucc_c

HTH,
Johan

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2367795

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-03 14:37:09 CEST

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.