> -----Oorspronkelijk bericht-----
> Van: Johan Corveleyn [mailto:johan.corveleyn_at_uz.kuleuven.ac.be]
> > -----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
Doh! You don't need svnmucc at all to do this in one single commit on the server. I forgot about a very interesting option of svn copy:
--parents : make intermediate directories
So, all you have to do to create a "sparse tag" is, with a command line svn client:
$ svn cp --parents <url>/Project1 <url>/Library1 <url>/Library2 <url>/tags/Project1/release1.0
And to tag Project2:
$ svn cp --parents <url>/Project2 <url>/Library2 <url>/tags/Project2/release1.0
But, as you said, you use TortoiseSVN. I don't think there is a way to do this from TortoiseSVN currently.
Regards,
Johan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2368874
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-07 16:41:27 CEST