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

Re: [rfc]Checkout without the .svn Directories

From: Anthony Metcalf <anthony.metcalf_at_anferny.ath.cx>
Date: 2004-12-03 16:18:02 CET

On Fri, 3 Dec 2004 15:57:51 +0100
Vincent Lefevre <vincent+svn@vinc17.org> wrote:

> > Obviously svn up would have to be changed for what I want to work.
> > Would it be a very big change?
>
> This is impossible. To be able to do an update (in the sense of
> revision control systems), svn must know on which version the
> file is based (you need this information for each file: either
> a revision or information saying that the file is unversioned),
> and possibly information related to some properties.
>

The idea being, the whole tree would be treated as one. Hence just the
one revsion number at the top of the tree.

> > The whole tree is kept at the same revision. All the time.
>
> The problem is: What if an update has partially failed, so that
> some files have already been updated, but not others?

svn uses atomic transactions I read. Would it be very hard to make it so
that when an svn up is done on an exported tree the whole tree was
treated as one entity.

At the end of the day, if an svn up failed on this type of three the
user could simply be advised to re-export it.

The whole point of this idea is that for an export all the revision
control is stripped away except for the tree as a whole; that tree can
beonly at a specific revision.

I could no doubt implement what I want by writing a wrapper that deleted
the tree, checked out the tree, and then recursivly deleted the .svns.
It would be nicer to have this built into subversion though.

  • application/pgp-signature attachment: stored
Received on Fri Dec 3 16:23:40 2004

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.