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
Received on Tue Jul 22 15:40:02 2003