You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Sindbad the Seafarer <si...@gmx.net> on 2003/07/19 10:43:54 UTC
.SVN folder question
Hi all out there!
If I understood correctly this was a thread some time ago under the
name of "SVN droppings":
I want to use Subversion for web site production. However, it puts a
hidden folder ".svn" into each directory of my working copy. Of
course I rather not want to see this folder uploaded, both for
webspace and online transfer time/cost. I can filter out these
Subversion folders in the FTP app I use (TotalCommander, formerly
Windows Commander), but as I have to set this filter again for
every upload this is not very convenient (though more related to
TotalComm than Subversion).
However, when shortly testing Perforce I found that for version
control it is not mandatory to place administrative data into the
working copy. So the question Is there already a setting to move
these hidden folders to another place, either a central folder in the
working copy or even elsewhere? Or could this be seen as a
suggestion for future releases?
BTW testing Perforce was an outright desaster. First, I could not
hit F1 without it trying to connect to the web - and that for every
help page I might then choose from the contents again! Second,
since being practically unable to use help I could not find a working
way to put folders/subfolders under versioning. Integration with
HTML editor Homesite is buggy and limited anyway. And just this
was the reason I tried Perforce at all. Thus I now continue with
setting up Subversion, first locally, then on the LAN.
TIA - God bless!
Jan Hendrik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: .SVN folder question
Posted by Sindbad the Seafarer <si...@gmx.net>.
Concerning Re: .SVN folder question
Garrett Rooney wrote on 22 Jul 2003, 9:44, at least in part:
> Sindbad the Seafarer wrote:
>
> > That's too high for my - limited would still be a euphemism -
> > programming skills! <G> However, after about a week of trial and
> > error I am about to give up on version control at all. Sometimes
> > everything works allright, added folders appear at correct place in
> > the other working copy, too. And then again further added folders
> > show up in the root of the second wc. But when I delete & commit
> > them in wc2 and then update wc1 and try to add those folders again I
> > get errors like "already exists", "not locked" etc. I am at the end
> > of my wits and patience.
>
> If you can give us a list of steps to reproduce these problems, we'd
> appreciate it. As it is, just saying "i get errors like..." isn't
> even close to enough information to begin to debug the problem.
True enough, Garrett ... However, I don't have written down the
commands, partly even used TortoiseSVN, and it's impossible to
reconstruct. Meanwhile I have deleted everything, the repository, all
working copies and tried to start from scratch. Creating a new
repos was no problem (upper/lowercase as entered at the
command line, no tortoise this time):
svnadmin create d:\SVNRepos
-> OK, worked, repos and four subfolders appear in filemanager;
svn import -m "initial import" d:\import
http://192.168.0.2/svn/SVNRepos
-> svn: Bad URL passed to RA layer
-> svn: illegal URL for repository
then:
svn mkdir http://192.168.0.2/svn/trunk -m "add trunk"
-> svn: RA layer request failed
-> svn: OPTIONS request failed on '/svn'
-> svn: The OPTIONS request returned invalid XML in the response:
XML parse error at line 1: no element found. (/svn)
That's it. I can't import, can't make a new folder. Substituting http
with svn returns Host not known.
Subversion .25, Apache2 running, 192.168.0.2 shows default test
page in browser, 192.168.0.2/svn/ brings up the Forbidden page.
Working on the same machine as repository and Apache, Win2K.
Before *this* part had worked without trouble. d:\import contains
three empty folders: trunk, branches, taggs as recommended in
Tortoise User Guide and virtually following the book.
But maybe this is a clue to those troubles above: that first
repository was first imported/committed to locally (file:///). Later I
turned to use http:// to test things most realistically before
spreading versioning over the LAN to the other user.
Perhaps either http:// has never worked correctly here or the switch
from file:/// to http:// had corrupted the repository in some way.
Dunno if this is of any help for you and others, I can't go on,
attempting to get into version control since Monday last week
without having achieved anything so far (despite of a promising
start) I have to get back to my regular work now and must do as
before: without versioning. Sorry, but that's how things are. Even
though I suspect that I am just two or three further days apart from
success. While working on a test site for another fortnight or so to
get used to versioning would have been OK, without even a basic
repository so far this is beyond any dream. The failure of Perforce
set aside guys like me should never go for beta software. On
another occasion I even drowned any plans to upgrade my email
app since first official releases of Pegasus 4 had been reported that
unstable. Therefore thanks a lot to all of you for your various help
since last week and good luck!
Best regards - God bless!
Jan Hendrik
>
> -garrett
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: .SVN folder question
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Sindbad the Seafarer wrote:
> That's too high for my - limited would still be a euphemism -
> programming skills! <G> However, after about a week of trial and
> error I am about to give up on version control at all. Sometimes
> everything works allright, added folders appear at correct place in
> the other working copy, too. And then again further added folders
> show up in the root of the second wc. But when I delete & commit
> them in wc2 and then update wc1 and try to add those folders
> again I get errors like "already exists", "not locked" etc. I am at the
> end of my wits and patience.
If you can give us a list of steps to reproduce these problems, we'd
appreciate it. As it is, just saying "i get errors like..." isn't even
close to enough information to begin to debug the problem.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: .SVN folder question
Posted by Sindbad the Seafarer <si...@gmx.net>.
Concerning Re: .SVN folder question Jack Repenning wrote on 21
Jul 2003, 8:55, at least in part:
> At 1:23 PM +0200 7/20/03, Sindbad the Seafarer wrote:
> >
> >Of course the term "export" does not imply that timestamps are
> >preserved as in "copy". Nevertheless it would perhaps be of general
> >preferrence, also for the first checkout to a new working copy, to
> >have the timestamp reflecting the true creation/change time of the
> >file. I assume that implementating this is a lot easier for exporting
> >from a wc than from the repository when files are actually created
> >from the database.
>
> Hmmm ... are we talking about the same thing here? I think you're
> saying that "the human-language term 'export' does not imply...,"
That's what I meant indeed.
> which may well be true, but the point I was making is that "the
> Subversion subcommand 'svn export' really ought to create files with
> timestamps matching the last-commit times, rather than the time of
> export." 'svn export' also produces a set of files without the .svn
> directories, which is sort of how we got started on this topic. So a
> commit-time-preserving 'svn export' seems to meet the needs of the
> website maintenance.
Indeed again.
> There at the end of the paragraph, you may be referring to the
> difference between the timestamp of "when did I last edit this file"
> rather than "when did I get around to checking it into the
> repository." We did have some discussion of this distinction on the
> list; I think the upshot was that, while this makes perfect sense for
> a one-user repository, it's not so clear when there are multiple
> users changing private copies. Only at the moment when they commit
> is any correlation done against the work of others (merge-conflict
> checking, for example), making the commit time a more general point
> of coordination.
Agreed. However, I had not thought of the timestamp difference of
course normal between repository and working copy, I just thought
that export from a working copy might be implemented similar to or
even with direct use of OS copy with just a filter to exclude the
.SVN folders. That way the destination files would have the same
timestamp as in the working copy. If exported from the repository it
would be barely possible to give the files a timestamp other than
last commit (besides export time as current) of course. I think
having last commit time if exporting from repository and last
change time if exporting from working copy would suit everyone
best, both the single user as multiple users.
> What I have in mind for my website (but haven't actually assembled,
> yet) is a script that does something like this:
That's too high for my - limited would still be a euphemism -
programming skills! <G> However, after about a week of trial and
error I am about to give up on version control at all. Sometimes
everything works allright, added folders appear at correct place in
the other working copy, too. And then again further added folders
show up in the root of the second wc. But when I delete & commit
them in wc2 and then update wc1 and try to add those folders
again I get errors like "already exists", "not locked" etc. I am at the
end of my wits and patience. I need to get back to regular work and
think it might still be easier to co-ordinate file access in a group of
two by word of mouth than by software ... It had worked on a first
attempt with a site that has only a few folders below its root folder,
but with a more complex site with several levels of folders the good
start has become the beginning of a nightmare. Think I delete what
I have so far and start with new repository and two new working
copies and spend another day on it, but then - good bye!
Jan Hendrik
> svn export URL-TO-WEBSITE-IN-REPOSITORY temporarysite
>
> find temporarysite -type f -newer temporarysite/.exportmarker |
> xargs scp <file-list> THE-REAL-WEBSITE
>
> rm -fr temporarysite
>
> date > localsitewc/.exportmarker
>
> svn commit localsitewc
>
> --
> -==-
> Jack Repenning
> CollabNet, Inc.
> 8000 Marina Boulevard, Suite 600
> Brisbane, California 94005
> o: 650.228.2562
> c: 408.835-8090
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: .SVN folder question
Posted by Jack Repenning <jr...@collab.net>.
At 1:23 PM +0200 7/20/03, Sindbad the Seafarer wrote:
>
>Of course the term "export" does not imply that timestamps are
>preserved as in "copy". Nevertheless it would perhaps be of general
>preferrence, also for the first checkout to a new working copy, to
>have the timestamp reflecting the true creation/change time of the
>file. I assume that implementating this is a lot easier for exporting
>from a wc than from the repository when files are actually created
>from the database.
Hmmm ... are we talking about the same thing here? I think you're
saying that "the human-language term 'export' does not imply...,"
which may well be true, but the point I was making is that "the
Subversion subcommand 'svn export' really ought to create files with
timestamps matching the last-commit times, rather than the time of
export." 'svn export' also produces a set of files without the .svn
directories, which is sort of how we got started on this topic. So a
commit-time-preserving 'svn export' seems to meet the needs of the
website maintenance.
There at the end of the paragraph, you may be referring to the
difference between the timestamp of "when did I last edit this file"
rather than "when did I get around to checking it into the
repository." We did have some discussion of this distinction on the
list; I think the upshot was that, while this makes perfect sense for
a one-user repository, it's not so clear when there are multiple
users changing private copies. Only at the moment when they commit
is any correlation done against the work of others (merge-conflict
checking, for example), making the commit time a more general point
of coordination.
What I have in mind for my website (but haven't actually assembled,
yet) is a script that does something like this:
svn export URL-TO-WEBSITE-IN-REPOSITORY temporarysite
find temporarysite -type f -newer temporarysite/.exportmarker |
xargs scp <file-list> THE-REAL-WEBSITE
rm -fr temporarysite
date > localsitewc/.exportmarker
svn commit localsitewc
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: .SVN folder question
Posted by Sindbad the Seafarer <si...@gmx.net>.
Concerning Re: .SVN folder question
Jack Repenning wrote on 19 Jul 2003, 11:47, at least in part:
> At 6:33 PM +0200 7/19/03, Sindbad the Seafarer wrote:
> >Concerning Re: .SVN folder question
> >Ben Collins-Sussman wrote on 19 Jul 2003, 7:13, at least in part:
> > > 1. Try 'svn export'. It's like a checkout, but produces an
> > > unversioned tree (i.e. no .svn/ folders)
> >
> >This would be even worse I suppose: it does not keep the file dates
> >from the working copy but in truth re-creates the files at the
> >destination.
>
> Ooh! Ooh! Another use-case for preserving commit times on export!
>
> Sinbad: although "svn export" presently does what you say, we
> recently agreed that it really make the files have the timestamp of
> when they were last checked into SVN. It's turning out to be a
> little harder to do than expected (different operating systems do it
> in different ways), but I think it's still in the plan. So once
> that's done, you'll be able to 'svn export' the while web tree, and
> upload only the changed files, and search engines won't be tricked
> into uploading unchanged files.
Of course the term "export" does not imply that timestamps are
preserved as in "copy". Nevertheless it would perhaps be of general
preferrence, also for the first checkout to a new working copy, to
have the timestamp reflecting the true creation/change time of the
file. I assume that implementating this is a lot easier for exporting
from a wc than from the repository when files are actually created
from the database.
> Also, Ben asked:
> >Why not do what most of us do? Keep the working copy on the web
> >server, and make it the "live" tree served to the world.
>
> I don't know about Sinbad, but I don't run my own web server (my ISP
> does), and it doesn't have SVN installed. I do run my own SVN repo,
> and do my website maintenance from my own machine, but when I like my
> changes I have to upload them still. (I don't want to serve my
> website through my DSL, nor yet from my pesonal computer).
Things here are the very same (except for DSL not available in the
country side here), the ISP even does not allow telnet (in case that
could ease things, don't have any experience with telnet). However,
now I see my idea of keeping a "live" working copy on the server
updated via svn up would not work with ftp:// for protocol reasons.
When paying for webspace having the admin folders on the server
is not especially desireable anyway. Thus I think till the .SVN
folders are moveable to a central place in either the working copy
or even just on the local disk I'll prefer entering a filter in the FTP
app anytime I want to upload. And since exporting 60+MB any
other day just for an upload of a few changes is also time-
consuming it's not too big an inconvenience compared with the
other options ...
Jan Hendrik
marine niemeyer
jan hendrik niemeyer
- since 1992 -
dorfstrasse 4
27632 padingbuettel / germany
phone / fax +49 (0) 4742-2117
-----------------------------
visit our website:
http://www.marine-niemeyer.com
> Jack Repenning
> CollabNet, Inc.
> 8000 Marina Boulevard, Suite 600
> Brisbane, California 94005
> o: 650.228.2562
> c: 408.835-8090
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: .SVN folder question
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Sindbad the Seafarer wrote:
> New idea to me ('course everything connected with versioning is
> absolutely new, virginal land to me!). The command would then be
> something like
>
> svn update ftp://myserver.com
>
> and could be put into a batch file opening an FTP session, logging
> on, issuing the above update command and then logging off and
> closing the FTP session (should get the exact commands from the
> logfile of WinComm)? Only the first time a complete checkout
> would be necessary, wouldn't it?
Umh, why not simply check it out locally and then rsync the entire
working copy to your website? You'd only end up transfering the whole
thing the first time, after that it would be just diffs.
As for the ftp:// syntax, it sounds /way/ too much like creeping
featuritis, and is the kind of thing that should be implemented in a
script wrapping svn, if at all, not in the base application.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: .SVN folder question
Posted by Sindbad the Seafarer <si...@gmx.net>.
Concerning Re: .SVN folder question
B. W. Fitzpatrick wrote on 19 Jul 2003, 11:52, at least in part:
>
> Ben Collins-Sussman <su...@collab.net> writes:
> > "Sindbad the Seafarer" <si...@gmx.net> writes:
> >
> > > > 1. Try 'svn export'. It's like a checkout, but produces an
> > > > unversioned tree (i.e. no .svn/ folders)
> > >
> > > This would be even worse I suppose: it does not keep the file dates
> > > from the working copy but in truth re-creates the files at the
> > > destination. Thus all files are be new and uploaded to the
> > > webserver. While some searchengines are said to love files with
> > > new file date it would cause daily uploads of 60+ MB, perhaps even
> > > far more than just including the .svn folders. For that reason I
> > > already did not import anything to the newly created repository but
> > > only made a trunk folder and checked this practically empty repos
> > > out. Then copied the existing files in the file manager to that bare
> > > bones working copy and added them to the repos from there. This
> > > way all file dates/attributes remained unchanged and I can continue
> > > synchronizing with the web server as before (.svn folders aside).
> >
> > Why not do what most of us do? Keep the working copy on the web
> > server, and make it the "live" tree served to the world. Just 'svn
> > update' the live copy from time to time, rather than "reuploading" a
> > whole new tree to the server.
> >
> > In fact, I even have a post-commit hook in my repository which
> > automatically updates my live working copy.
New idea to me ('course everything connected with versioning is
absolutely new, virginal land to me!). The command would then be
something like
svn update ftp://myserver.com
and could be put into a batch file opening an FTP session, logging
on, issuing the above update command and then logging off and
closing the FTP session (should get the exact commands from the
logfile of WinComm)? Only the first time a complete checkout
would be necessary, wouldn't it?
> You might also want to add this to your httpd.conf to prevent people
> from peeking inside your .svn directories:
>
> --------------------8-<-------cut-here---------8-<-----------------------
> # Disallow browsing of Subversion working copy administrative
> # directories.
> <DirectoryMatch "^/.*/\.svn/">
> Order deny,allow
> Deny from all
> </DirectoryMatch>
> --------------------8-<-------cut-here---------8-<-----------------------
Thanks, Brian!
Jan Hendrik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: .SVN folder question
Posted by Ben Collins-Sussman <su...@collab.net>.
"Sindbad the Seafarer" <si...@gmx.net> writes:
> > 1. Try 'svn export'. It's like a checkout, but produces an
> > unversioned tree (i.e. no .svn/ folders)
>
> This would be even worse I suppose: it does not keep the file dates
> from the working copy but in truth re-creates the files at the
> destination. Thus all files are be new and uploaded to the
> webserver. While some searchengines are said to love files with
> new file date it would cause daily uploads of 60+ MB, perhaps even
> far more than just including the .svn folders. For that reason I
> already did not import anything to the newly created repository but
> only made a trunk folder and checked this practically empty repos
> out. Then copied the existing files in the file manager to that bare
> bones working copy and added them to the repos from there. This
> way all file dates/attributes remained unchanged and I can continue
> synchronizing with the web server as before (.svn folders aside).
Why not do what most of us do? Keep the working copy on the web
server, and make it the "live" tree served to the world. Just 'svn
update' the live copy from time to time, rather than "reuploading" a
whole new tree to the server.
In fact, I even have a post-commit hook in my repository which
automatically updates my live working copy.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: .SVN folder question
Posted by Jack Repenning <jr...@collab.net>.
At 6:33 PM +0200 7/19/03, Sindbad the Seafarer wrote:
>Concerning Re: .SVN folder question
>Ben Collins-Sussman wrote on 19 Jul 2003, 7:13, at least in part:
> > 1. Try 'svn export'. It's like a checkout, but produces an
> > unversioned tree (i.e. no .svn/ folders)
>
>This would be even worse I suppose: it does not keep the file dates
>from the working copy but in truth re-creates the files at the
>destination.
Ooh! Ooh! Another use-case for preserving commit times on export!
Sinbad: although "svn export" presently does what you say, we
recently agreed that it really make the files have the timestamp of
when they were last checked into SVN. It's turning out to be a
little harder to do than expected (different operating systems do it
in different ways), but I think it's still in the plan. So once
that's done, you'll be able to 'svn export' the while web tree, and
upload only the changed files, and search engines won't be tricked
into uploading unchanged files.
Also, Ben asked:
>Why not do what most of us do? Keep the working copy on the web
>server, and make it the "live" tree served to the world.
I don't know about Sinbad, but I don't run my own web server (my ISP
does), and it doesn't have SVN installed. I do run my own SVN repo,
and do my website maintenance from my own machine, but when I like my
changes I have to upload them still. (I don't want to serve my
website through my DSL, nor yet from my pesonal computer).
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: .SVN folder question
Posted by Sindbad the Seafarer <si...@gmx.net>.
Concerning Re: .SVN folder question
Ben Collins-Sussman wrote on 19 Jul 2003, 7:13, at least in part:
> "Sindbad the Seafarer" <si...@gmx.net> writes:
>
> > I want to use Subversion for web site production. However, it puts a
> > hidden folder ".svn" into each directory of my working copy. Of
> > course I rather not want to see this folder uploaded, both for
> > webspace and online transfer time/cost. I can filter out these
> > Subversion folders in the FTP app I use (TotalCommander, formerly
> > Windows Commander), but as I have to set this filter again for every
> > upload this is not very convenient (though more related to TotalComm
> > than Subversion).
>
> 1. Try 'svn export'. It's like a checkout, but produces an
> unversioned tree (i.e. no .svn/ folders)
This would be even worse I suppose: it does not keep the file dates
from the working copy but in truth re-creates the files at the
destination. Thus all files are be new and uploaded to the
webserver. While some searchengines are said to love files with
new file date it would cause daily uploads of 60+ MB, perhaps even
far more than just including the .svn folders. For that reason I
already did not import anything to the newly created repository but
only made a trunk folder and checked this practically empty repos
out. Then copied the existing files in the file manager to that bare
bones working copy and added them to the repos from there. This
way all file dates/attributes remained unchanged and I can continue
synchronizing with the web server as before (.svn folders aside).
So setting the filter in Windows/Total Commander is still the better
way. I already contacted Mr. Ghisler, the author of that app, for an
option to make that filter sticky in file synch, but it would be great if
others on this list also using WinComm would ask him, too.
> 2. We have post-1.0 plans someday that might allow .svn/ dirs to live
> outside a working copy... but that's long-term.
That would be great. I suppose that for software development it
really does not matter, but for web site production it would make
things a lot more user friendly and straightforward and thus broaden
the usability of Subversion. Of course as a non-programmer I have
no idea how much work this change would cause ...
Have a fine Sunday!
Jan Hendrik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: .SVN folder question
Posted by Ben Collins-Sussman <su...@collab.net>.
"Sindbad the Seafarer" <si...@gmx.net> writes:
> I want to use Subversion for web site production. However, it puts a
> hidden folder ".svn" into each directory of my working copy. Of
> course I rather not want to see this folder uploaded, both for
> webspace and online transfer time/cost. I can filter out these
> Subversion folders in the FTP app I use (TotalCommander, formerly
> Windows Commander), but as I have to set this filter again for
> every upload this is not very convenient (though more related to
> TotalComm than Subversion).
1. Try 'svn export'. It's like a checkout, but produces an
unversioned tree (i.e. no .svn/ folders)
2. We have post-1.0 plans someday that might allow .svn/ dirs to live
outside a working copy... but that's long-term.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org