You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Anthony Metcalf <an...@anferny.ath.cx> on 2004/12/02 09:18:59 UTC
[rfc]Checkout without the .svn Directories
Hi,
Firstly let me apologise if this has been asked before, please point me
at the correct pleace to see the old discussion if it has.
Am I correct in thinking that with all the .svn directories, a
directory tree will take up twice as much space as the directory tree
without the .svns would take? If not the rest of this is useless babble!
Now. I have one or two repo's which are checked out to specific place,
and never modified from there. I.e. the only actions ever taken are "svn
co..." and "svn up".
A good example of this is our intranet. It is accessable from two
places, and modified by me, on my own destop. I only need the .svn
directories on my desktop, as this is the only place I modify files.
What I would like, is a cammand such as "svn export ..." syntacticly
identical to svn checkout. The difference being, there would only be 1
.svn directory.
This would be in the top level, and would contain 1 file, which contains
the revision number. That's it, nothing else.
the "svn" command could then be modified to check if the current tree
was checked out or exported, and if exported, only allow svn up.
Is this feasable?
Re: [rfc]Checkout without the .svn Directories
Posted by Anthony Metcalf <an...@anferny.ath.cx>.
On Fri, 3 Dec 2004 16:18:17 +0000
Jeremy Pereira <je...@ntlworld.com> wrote:
> Why not just use "svn export"? OK, it means the whole tree has to
> come across from the server. Is your tree too massive to do that?
That does everything I want, except I cannot update it.
I guess my question now becomes, could svn up be made to work from
within an exported tree?
Re: [rfc]Checkout without the .svn Directories
Posted by Jeremy Pereira <je...@ntlworld.com>.
On Dec 2, 2004, at 09:18, Anthony Metcalf wrote:
> Hi,
>
> Firstly let me apologise if this has been asked before, please point
> me
> at the correct pleace to see the old discussion if it has.
>
> Am I correct in thinking that with all the .svn directories, a
> directory tree will take up twice as much space as the directory tree
> without the .svns would take? If not the rest of this is useless
> babble!
>
> Now. I have one or two repo's which are checked out to specific place,
> and never modified from there. I.e. the only actions ever taken are
> "svn
> co..." and "svn up".
>
> A good example of this is our intranet. It is accessable from two
> places, and modified by me, on my own destop. I only need the .svn
> directories on my desktop, as this is the only place I modify files.
>
> What I would like, is a cammand such as "svn export ..." syntacticly
> identical to svn checkout. The difference being, there would only be 1
> .svn directory.
Why not just use "svn export"? OK, it means the whole tree has to come
across from the server. Is your tree too massive to do that?
>
> This would be in the top level, and would contain 1 file, which
> contains
> the revision number. That's it, nothing else.
>
> the "svn" command could then be modified to check if the current tree
> was checked out or exported, and if exported, only allow svn up.
>
> Is this feasable?
>
>
--
Jeremy Pereira
http://www.jeremyp.net
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [rfc]Checkout without the .svn Directories
Posted by Anthony Metcalf <an...@anferny.ath.cx>.
On Wed, 8 Dec 2004 10:44:24 -0500
Josh Pieper <jj...@pobox.com> wrote:
> See the thread in http://svn.haxx.se/dev/archive-2004-11/0337.shtml
> for what the dev opinion is of this feature. Basically it isn't
> expected anytime soon.
Thanks.
I'm happy with that.
Re: [rfc]Checkout without the .svn Directories
Posted by Josh Pieper <jj...@pobox.com>.
Anthony Metcalf wrote:
> I will ask the question I was trying to get at in the biginning.
>
> Would it be difficult to alter svn up to
> 1) recognise it is in an exported tree.
> 2) grab a number from a file in a .svn directory.
> 3) assume the number grabbed in 2 is a revision number.
> 4) transfer only the files that have changed since the revision in 3.
> 5) update the number in the file in the .svn directory to the current
> revision number.
>
> ???
>
> A yes or no from a dev is what I'm after, not anopther way of doing
> this.
See the thread in http://svn.haxx.se/dev/archive-2004-11/0337.shtml
for what the dev opinion is of this feature. Basically it isn't
expected anytime soon.
-Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [rfc]Checkout without the .svn Directories
Posted by Anthony Metcalf <an...@anferny.ath.cx>.
On Wed, 08 Dec 2004 16:03:47 +0100
Niels Skou Olsen <ns...@manbw.dk> wrote:
> With regard to ease, I can't see it being any easier than a simple
> 'svn up' command. With regard to disk space, you say yourself that
> it's a working copy of modest size. And besides, disk space is cheap
> these days. :-)
>
My point is, would it be very difficult to alter svn up to
recognise/update an exported tree. I want to use "svn up" as a command,
I want to use it in an exported tree. Bandwidth doesn't bother me, disk
space in this instance does. I don't see the point of keeping two copies
of the same thing, one of which is never used.
> > i.e. "Whats the point of keeping two copies of the repo on a disk
> > when this wc will *never* be modified directly?".
>
> The point is, as I see it, to minimize the number of server
> round-trips, and when server round-trips *are* necessary, then only
> exchange diffs with the server. This gives the best overall
> performance.
I will ask the question I was trying to get at in the biginning.
Would it be difficult to alter svn up to
1) recognise it is in an exported tree.
2) grab a number from a file in a .svn directory.
3) assume the number grabbed in 2 is a revision number.
4) transfer only the files that have changed since the revision in 3.
5) update the number in the file in the .svn directory to the current
revision number.
???
A yes or no from a dev is what I'm after, not anopther way of doing
this.
I apologise if I sound exasperated. I am. I am not asking for
workarounds to what I see are problems (I could simply rm -rf the tree
and svn export it every time), I am trying to see if the modification I
suggested above would be possible, and then asking someone more familier
with the source to do that modification, in order to make my life
easier.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [rfc]Checkout without the .svn Directories
Posted by Niels Skou Olsen <ns...@manbw.dk>.
Anthony Metcalf <an...@anferny.ath.cx> writes:
> On Wed, 08 Dec 2004 15:29:18 +0100
> Niels Skou Olsen <ns...@manbw.dk> wrote:
>
>> Come to think of it.. If OP's goal is to keep a huge working copy
>> updated with the least possible amount of network traffic, then just
>> do the obvious; make a normal working copy with 'svn co' and keep it
>> updated with'svn up'. This way you pay up front with a full 'svn co',
>> but you pay only once. All 'svn up' after this will be as cheap as can
>> be.
>
> No OP's (my) goal is to keep a copy of a modest repo up to date with the
> least effort, and least disk space. Low bandwidth would be nice, but
> disk space is the primary concern, followed by ease, and not having to
> remember a different command for this server.
With regard to ease, I can't see it being any easier than a simple 'svn up'
command. With regard to disk space, you say yourself that it's a working
copy of modest size. And besides, disk space is cheap these days. :-)
> i.e. "Whats the point of keeping two copies of the repo on a disk when
> this wc will *never* be modified directly?".
The point is, as I see it, to minimize the number of server round-trips,
and when server round-trips *are* necessary, then only exchange diffs with
the server. This gives the best overall performance.
Best regards,
Niels
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [rfc]Checkout without the .svn Directories
Posted by Anthony Metcalf <an...@anferny.ath.cx>.
On Wed, 08 Dec 2004 15:29:18 +0100
Niels Skou Olsen <ns...@manbw.dk> wrote:
> Come to think of it.. If OP's goal is to keep a huge working copy
> updated with the least possible amount of network traffic, then just
> do the obvious; make a normal working copy with 'svn co' and keep it
> updated with'svn up'. This way you pay up front with a full 'svn co',
> but you pay only once. All 'svn up' after this will be as cheap as can
> be.
No OP's (my) goal is to keep a copy of a modest repo up to date with the
least effort, and least disk space. Low bandwidth would be nice, but
disk space is the primary concern, followed by ease, and not having to
remember a different command for this server.
i.e. "Whats the point of keeping two copies of the repo on a disk when
this wc will *never* be modified directly?".
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [rfc]Checkout without the .svn Directories
Posted by Niels Skou Olsen <ns...@manbw.dk>.
Niels Skou Olsen <ns...@manbw.dk> writes:
> Fraser Campbell <fr...@georgetown.wehave.net> writes:
>
>> On Thursday 02 December 2004 04:18, Anthony Metcalf wrote:
>
> [...]
>
>> You're basically after a bandwidth/time efficient way of bringing an export up
>> to date. With a large tree I can see that this would be very useful.
>
> [use diff/patch to keep an export updated]
>
>> diff doesn't tell you the HEAD revision number so you'd have to grab that
>> yourself in another way and update the .exportrev file. You could write a
>> wrapper script to automate the whole thing in a few minutes.
>
> But diff/patch doesn't handle directory tree changes (add, remove, rename
> etc). So this method will never be able to truely keep an export up to
> date.
Come to think of it.. If OP's goal is to keep a huge working copy updated
with the least possible amount of network traffic, then just do the
obvious; make a normal working copy with 'svn co' and keep it updated with
'svn up'. This way you pay up front with a full 'svn co', but you pay only
once. All 'svn up' after this will be as cheap as can be.
Best regards,
Niels
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [rfc]Checkout without the .svn Directories
Posted by Steve Greenland <st...@lsli.com>.
This is sort of topic, but I feel a need to comment:
On Wed, Dec 08, 2004 at 12:11:26PM -0500, Matthias Julius wrote:
> Another good reason for larger projects to avoid a full export is that
> after the export make (or other tools) can not know what files have
> changed and you have to rebuild the whole thing just because one
> file has been modified.
That's not necessarily a bad thing. If this is a developer tree, then
you should be using checkout, not export, and so this is not an issue.
So I'm going to guess that this is your autobuild/integration/snapshot
tree. In that case, you *do* want to build it from scratch every time.
Large projects tend to use recursive makes, and recursive makes often
have incomplete dependency graphs (because maintaining the complete
graph is basically impossible), and therefore building from scratch is
the only way to determine that you have a completely consistent build.
Steve
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask
about Exchange Server next.
-- (Stolen from the net)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [rfc]Checkout without the .svn Directories
Posted by Matthias Julius <jn...@julius-net.net>.
Niels Skou Olsen <ns...@manbw.dk> writes:
> But diff/patch doesn't handle directory tree changes (add, remove, rename
> etc). So this method will never be able to truely keep an export up to
> date.
And, if something goes wrong it takes some effort to find out which
file is in which revision or you have to make a new clean export.
What I would like is something like 'svn export -r150:HEAD source
target' which would export files that have changed between revisions
150 and HEAD and also delete files that have been deleted from the
repository.
Another good reason for larger projects to avoid a full export is that
after the export make (or other tools) can not know what files have
changed and you have to rebuild the whole thing just because one
file has been modified.
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [rfc]Checkout without the .svn Directories
Posted by Niels Skou Olsen <ns...@manbw.dk>.
Fraser Campbell <fr...@georgetown.wehave.net> writes:
> On Thursday 02 December 2004 04:18, Anthony Metcalf wrote:
[...]
> You're basically after a bandwidth/time efficient way of bringing an export up
> to date. With a large tree I can see that this would be very useful.
[use diff/patch to keep an export updated]
> diff doesn't tell you the HEAD revision number so you'd have to grab that
> yourself in another way and update the .exportrev file. You could write a
> wrapper script to automate the whole thing in a few minutes.
But diff/patch doesn't handle directory tree changes (add, remove, rename
etc). So this method will never be able to truely keep an export up to
date.
Best regards,
Niels
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [rfc]Checkout without the .svn Directories
Posted by Fraser Campbell <fr...@georgetown.wehave.net>.
On Thursday 02 December 2004 04:18, Anthony Metcalf wrote:
> the "svn" command could then be modified to check if the current tree
> was checked out or exported, and if exported, only allow svn up.
You're basically after a bandwidth/time efficient way of bringing an export up
to date. With a large tree I can see that this would be very useful.
Still, you can do what you want fairly easily already. Export the tree and
record your revision number somewhere. When you want to update do a diff
between your exported revision and head and then apply the patch. These
commands should work on most decent operating systems ;-)
First the checkout:
shieldaig$ svn export http://svn.wehave.net/svn/fraser/home/.kde
A .kde
A .kde/share
A .kde/share/apps
A .kde/share/apps/knode
A .kde/share/apps/knode/nntp.1
A .kde/share/apps/knode/nntp.1/info
A .kde/share/apps/kabc
A .kde/share/apps/kabc/std.vcf
A .kde/share/apps/konqueror
A .kde/share/apps/konqueror/bookmarks.xml
A .kde/share/apps/konqueror/konqueror.rc
A .kde/share/config
A .kde/share/config/emaildefaults
A .kde/share/config/kcontrolrc
A .kde/share/config/kmailrc
A .kde/share/config/knoderc
A .kde/share/config/kcmdisplayrc
A .kde/share/config/khotkeysrc
A .kde/share/config/kontactrc
A .kde/share/config/ksplashrc
A .kde/share/config/korgacrc
A .kde/share/config/kickerrc
A .kde/share/config/kwinrc
A .kde/share/config/konsolerc
A .kde/share/config/khotkeys_update
A .kde/share/config/kdeglobals
A .kde/share/config/emailidentities
A .kde/share/config/kdesktoprc
A .kde/share/config/konquerorrc
A .kde/share/config/kopeterc
A .kde/Autostart
A .kde/Autostart/.directory
A .kde/Autostart/ssh-add
Exported revision 1800.
How you record the revision would be up to you. If the export operation is
done frequently then you would want it automated, otherwise I would simply do
"echo 1800 > .exportrev".
Now bringing the tree up to speed:
shieldaig$ svn diff -r 1800:HEAD \
http://svn.wehave.net/svn/fraser/home/.kde/ | \
patch -p0 -d .kde
patching file share/apps/kabc/std.vcf
patching file share/apps/konqueror/bookmarks.xml
patching file share/config/kmailrc
patching file share/config/kontactrc
patching file share/config/korgacrc
patching file share/config/kickerrc
patching file share/config/kwinrc
patching file share/config/konsolerc
patching file share/config/kdeglobals
patching file share/config/kdesktoprc
patching file share/config/konquerorrc
patching file share/config/kopeterc
patching file Autostart/.directory
diff doesn't tell you the HEAD revision number so you'd have to grab that
yourself in another way and update the .exportrev file. You could write a
wrapper script to automate the whole thing in a few minutes.
--
Fraser Campbell <fr...@wehave.net> http://www.wehave.net/
Georgetown, Ontario, Canada Debian GNU/Linux
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [rfc]Checkout without the .svn Directories
Posted by Matthias Julius <jn...@julius-net.net>.
Vincent Lefevre <vi...@vinc17.org> writes:
> If you have only one .svn directory, you can't do a svn up. What
> you need is probably something like rsync or unison.
What probably would be nice is a 'svn export' command that would only
export files that have changed since a certain revision. That would
be basically equivalent to 'rsync -avc --delete' but exporting
directly from the repository.
Than it would be easy to write a wrapper around it that stores the
actual revision number somewhere after a successfull export.
This would be very usefull everywhere where a large amount of data is
exported regularly. There a full export just because one file has
changed is a waste of resources and you might not want to keep all the
svn meta data araound.
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [rfc]Checkout without the .svn Directories
Posted by Anthony Metcalf <an...@anferny.ath.cx>.
On Sun, 5 Dec 2004 22:23:56 +0100
Vincent Lefevre <vi...@vinc17.org> wrote:
> > I don't understand what you mean.
>
> If a "svn up" has been interrupted, the next time a "svn up" is
> performed, svn wouldn't know whether a file has not been updated
> yet with "svn up" or were modified by the user.
>
Hmm I see what you mean. The way I would envision it though, the
revision number stored in the exported tree would only be updated after
all files have been transfered. Hence an svn up after a failed svn up,
would grab a load of files it does not need to.
How much of a problem this is would depend on how often svn up failed.
> > Let me re-itterate, you would *never* make any changes in this tree.
>
> In this case, I assume that you don't want a "svn up" (which takes
> into account modifications by the user -- and doesn't know that the
> user never makes change in your case), but some form of optimized
> svn export.
I don't really see the difference, except what you type.
Your right, the finctionality to recognise that this tree has been
exported before could be put into export; Or svn up could be altered to
see that it is in an exported tree not a checked out tree.
Re: [rfc]Checkout without the .svn Directories
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2004-12-03 17:14:08 +0000, Anthony Metcalf wrote:
> On Fri, 3 Dec 2004 17:55:29 +0100
> Vincent Lefevre <vi...@vinc17.org> wrote:
> > But then, svn wouldn't know the base of each file without a .svn
> > directory containing sufficient data.
>
> I don't understand what you mean.
If a "svn up" has been interrupted, the next time a "svn up" is
performed, svn wouldn't know whether a file has not been updated
yet with "svn up" or were modified by the user.
> Let me re-itterate, you would *never* make any changes in this tree.
In this case, I assume that you don't want a "svn up" (which takes
into account modifications by the user -- and doesn't know that the
user never makes change in your case), but some form of optimized
svn export.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [rfc]Checkout without the .svn Directories
Posted by Anthony Metcalf <an...@anferny.ath.cx>.
On Fri, 3 Dec 2004 17:55:29 +0100
Vincent Lefevre <vi...@vinc17.org> wrote:
> > svn uses atomic transactions I read.
>
> But they are not applied atomicly. AFAIK, you have to "svn cleanup"
> if something wrong happens (e.g. the network goes down at the wrong
> time).
>
Sounds reasonable enough.
> > 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.
>
> But then, svn wouldn't know the base of each file without a .svn
> directory containing sufficient data.
I don't understand what you mean.
As you can see from another post in this thread, I have just been
informed of the current "svn export". What I want is that. With the
exceptions that the revision number that is exported is also stored, and
svn up is usable from within this tree.
This is for a quite specific circumstance, where a failed svn up would
be a little inconvienient, but not a real problem, i.e. you can always
re-export. And be back at where you would have been had you done a
compleate svn up.
Let me re-itterate, you would *never* make any changes in this tree.
That is it's reason to exist.
Re: [rfc]Checkout without the .svn Directories
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2004-12-03 15:18:02 +0000, Anthony Metcalf wrote:
> On Fri, 3 Dec 2004 15:57:51 +0100
> Vincent Lefevre <vi...@vinc17.org> wrote:
> > 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.
But they are not applied atomicly. AFAIK, you have to "svn cleanup"
if something wrong happens (e.g. the network goes down at the wrong
time).
> 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.
But then, svn wouldn't know the base of each file without a .svn
directory containing sufficient data.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [rfc]Checkout without the .svn Directories
Posted by Anthony Metcalf <an...@anferny.ath.cx>.
On Fri, 3 Dec 2004 15:57:51 +0100
Vincent Lefevre <vi...@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.
Re: [rfc]Checkout without the .svn Directories
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2004-12-03 10:17:56 +0000, Anthony Metcalf wrote:
> On Thu, 2 Dec 2004 11:06:38 +0100
> Vincent Lefevre <vi...@vinc17.org> wrote:
>
> > If you have only one .svn directory, you can't do a svn up. What
> > you need is probably something like rsync or unison.
>
> But I don't have a set-up without the .svns anywhere at all at the
> moment!
>
> 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 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?
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [rfc]Checkout without the .svn Directories
Posted by Anthony Metcalf <an...@anferny.ath.cx>.
On Thu, 2 Dec 2004 11:06:38 +0100
Vincent Lefevre <vi...@vinc17.org> wrote:
> If you have only one .svn directory, you can't do a svn up. What
> you need is probably something like rsync or unison.
But I don't have a set-up without the .svns anywhere at all at the
moment!
Obviously svn up would have to be changed for what I want to work. Would
it be a very big change?
I notice that if I do svn <anything> in a directory without a .svn I get
"not under revision control" or some such.
What I am really asking for is a third case. i.e.
1) no .svn directory = not under rev control.
2) .svn exists (as it is now) = under normal revision control.
3) .svn contains just a version file = under export control.
Then svn up says, if under export control just update (recursivly) to
the latest revision. Updating the version in the top-level .svn
directory at the end.[1]
The whole tree is kept at the same revision. All the time.
This is a very limited type of checkout (hence the name export) but
would be useful to me, possibly to others.
Is it too great a job for the rewards?
[1] I can see two ways to do this.
1) Effectivly do another svn export.
2) Take the current revision number, do an svn diff -r <revision
number>:head, apply that diff.
I am in no position to say which would be better!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [rfc]Checkout without the .svn Directories
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2004-12-02 09:18:59 +0000, Anthony Metcalf wrote:
> Am I correct in thinking that with all the .svn directories, a
> directory tree will take up twice as much space as the directory tree
> without the .svns would take? If not the rest of this is useless babble!
This is because the base is cached, and it would be a good thing
if this were optional (possibly based on MIME types or other
patterns...).
> What I would like, is a cammand such as "svn export ..." syntacticly
> identical to svn checkout. The difference being, there would only be 1
> .svn directory.
>
> This would be in the top level, and would contain 1 file, which
> contains the revision number. That's it, nothing else.
>
> the "svn" command could then be modified to check if the current tree
> was checked out or exported, and if exported, only allow svn up.
If you have only one .svn directory, you can't do a svn up. What
you need is probably something like rsync or unison.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org