You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2004/07/17 13:45:50 UTC
Re: can I insert older versions of files? i.e. "here's backups of
3 months ago - put 'em in right revision order..."
On Fri, 2004-07-16 at 22:30, Alan Jay Weiner wrote:
> Maybe it's not worth it, but if it's possible to do, I'd really like to.
It's not possible to do what you want. The only thing you can do is
what the rest of us have done:
1. import a snapshot of an initial tree
2. checkout a working copy
3. unpack a new tree snapshot on top of the working copy
4. adjust working copy as needed
5. commit
6. goto step 3
Sorry. :-(
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: can I insert older versions of files? i.e. "here's backups of 3 months ago - put 'em in right revision order..."
Posted by Alan Jay Weiner <al...@ajw.com>.
>Per: Submission of older files into the REPOS, retain older date
>> > Maybe it's not worth it, but if it's possible to do, I'd really like to.
>>
>> It's not possible to do what you want. The only thing you can do is
>> what the rest of us have done:
>
>Actually, I just posed a similar question last week. I'll summarize
>what I have figured out so far....
Thanks, FRuG!
These notes did indeed help me! I'll expand on them to help others; I'm
running on Win2k and discovered some things...
>BACKGROUND NOTES:
>
>1) After importing the files into the REPOS, they'll have the 'current
>date/time' as the file date.
ick - hadn't realized that until I'd gone through my backups, committing all the
changes... so it looks like the entire project starts on 17 Jul 2004 - man, I
did a lot of work that day! :)
>2) When you 'export/checkout' the files, they'll have have "today's"
>date/time.
>
>3) You can retain original date/times, by turning on the
>'~/.subversion/config' option 'use-commit-times=yes'.
>
>4) You can turn on 'use-commit-times' globally for the whole system.
> (on the system that you are checking out files, /etc/subversion/config)
Thank you! I've set this on my system. For Windows users, you'll find
"config" in the user directory; on my machine it's:
C:\Documents and Settings\aweiner\Application Data\Subversion
(my user name is aweiner of course :)
That directory has config, servers, and README.txt, and an auth subdirectory
(automatically created when svn runs, if I remember correctly)
Edit config so you have these lines uncommented:
[miscellany]
use-commit-times = yes
I also uncommented: (and added *.obj to the list)
global-ignores = *.o *.obj *.tmp *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store
This is in the [miscellany] section also.
If you want to make these options global for everyone, copy that
C:\Documents and Settings\aweiner\Application Data\Subversion
directory (with config and servers files) to
C:\Documents and Settings\All Users\Application Data\Subversion
(qualification: I'm pretty sure that's right - I haven't done it yet 'cause
I'm just running Subversion locally on my notebook. And you probably should
*not* copy the "auth" subdirectory)
>SOLUTIONS:
>
>Here's two solutions . . . based on feedback from the 'Subversion
>Users' list and some of my own ideas:
>
>1) Use the 'svn:date' property to set the file date. [1]
> (I'm currently experimenting with a script to restore the dates
>after import)
I started playing with this - seems to work reasonably well. If I read things
right, then committing each file individually (creating a revision for each
file) then setting that revision to the desired timestamp will keep the files
matching the file's timestamp in my backups.
Yeah, seems like a lot of work for something I'll probably never care about...
:)
NOTES about changing svn:date on Windows:
1) the property name is 'svn:date' - the colon doesn't assign any meaning other
than it being a reserved name; i.e., ':' is just another letter. You could
create a property named "fred" if you want.
(I think this is right - confirmation, anyone?)
2) In order to change revision properties you need to create pre-revprop-change
and post-revprop-change scripts.
I believe they can be empty; they just need to exist to permit revision property
changes. (maybe they are needed - to return a "success" return code...)
They are both in the repository in the "hooks" directory. Subversion initially
populates that directory with templates (*.tmpl) for these hooks.
For Windows, they're batch (*.BAT) files.
NOTE WELL: the "success" return value for Windows is 0; the template returns 1
for success. Also note the changes to use Windows batch-file notation: % as a
environment-variable mark, double-equals in the if statement, etc.
NOTE: I tried doing "echo" messages and "pause" commands and had trouble - it
works in the post script, but didn't seem to work right in the pre-change
script. Not sure if I did something wrong or if it just doesn't work right in
the pre-change script. Just a warning...
Here's my pre-revprop-change.BAT file:
set REPOS=%1
set REV=%2
set USER=%3
set PROPNAME=%4
if "%PROPNAME%"=="svn:log" (
set returnval=1
) else (
set returnval=0
)
exit %returnval%
And here's my post-revprop-change.BAT file:
set REPOS=%1
set REV=%2
set USER=%3
set PROPNAME=%4
propchange-email.pl "%REPOS%" "%REV%" "%USER%" "%PROPNAME%" email@domain.com
You can comment out the last line if you don't have Perl or don't want
property-change emails...
The command to show the properties for the most recent revision ("HEAD") is:
svn proplist -v --revprop -r head
This will show something like:
Unversioned properties on revision 3:
svn:log : Removed file/folder
svn:author : TVPVR
svn:date : 2004-07-17T21:27:21.625000Z
The date format is ISO 8601, see http://www.w3.org/TR/NOTE-datetime
It is in this format: (this is copied from that page)
YYYY-MM-DDThh:mm:ss.sTZD
where:
YYYY = four-digit year
MM = two-digit month (01=January, etc.)
DD = two-digit day of month (01 through 31)
hh = two digits of hour (00 through 23) (am/pm NOT allowed)
mm = two digits of minute (00 through 59)
ss = two digits of second (00 through 59)
s = one or more digits representing a decimal fraction of a second
TZD = time zone designator (Z or +hh:mm or -hh:mm)
(Note the 'T' seperating the date and time)
To set the time of a revision, the command is:
svn propset svn:date '2004-07-17T12:00:00.000000Z' --revprop -r 3
HOWEVER: if you use the single-quotes in a Windows DOS box (aka "command
prompt") you'll get the error:
svn: 'pre-revprop-change' hook failed with error output:
(no error output is given; just the error message)
NOTE: If you try to look at the repository log, you'll also get an error "Date
parsing failed"
Google is your friend; I found an archived message at
http://www.contactor.se/~dast/svnusers/archive-2004-05/0748.shtml
that says the single-quotes get saved as part of the svn:date property value (on
Windows)
So the *real* command to use is:
svn propset svn:date 2004-07-17T12:00:00.000000Z --revprop -r 3
You'll get a response:
property 'svn:date' set on repository revision '3'
And
svn proplist -v --revprop -r 3
will then return:
Unversioned properties on revision 3:
svn:log : Removed file/folder
svn:author : TVPVR
svn:date : 2004-07-17T12:00:00.000000Z
>2) Dump the entire REPOS, then 'by a script' modify the commit times
>in that file for each
> file based on original files-date/times. Then re-import into a new REPOS.
Haven't tried dumping the REPO - may do that to see about how I could insert
intermediate backups (i.e., "I just found another backup from November..." :)
But that also - do I really care???
Yeah, I would - if someone *else* had done the work to import all the backups!
(big grin!!)
>Neither one is 'elegant' nor clean.
Yeah, and for limited likely use...
>FEATURE REQUEST:
>
>Ability to 1) Import or 2) Check-in , with SVN and retain the file
>dates, per option '--retain-file-dates' (or something like that). :)
I would *very* much like this too - I'm rather anal about timestamps, and it
really bothers me that they could change...
(to be honest - I think it's more that I'm used to a certain way of working, and
Subversion is a bit different. Not necessarily better/worse - just I'm old and
cranky and don't wanna change... I suspect once I'm using it for a few months
and it's all second-nature, I won't care about it at all...)
>
>Thanks,
>-FRuG
>
>Notes:
>[1] Original message:
>------------------------------------------------------------------------------------------------
>Ben Collins-Sussman <su...@collab.net> Fri, 09 Jul 2004 19:50:43 -0500
>
>Here's a possible trick:
>
>Organize your files into buckets, categorized by original dates. Then
>commit each "bucket" of files in chronological order. This results in a
>bunch of revisions in the repository. Then you can tweak each
>revision's 'svn:date' property, so it *appears* that each bucket of
>files was committed on a certain date.
>
>In other words, because a revision's svn:date property is tweakable, you
>can make the "commit times" of the files match the original times.
>------------------------------------------------------------------------------------------------
Ah - this is what I just asked Ben... I guess it *will* work... :)
The downside (or at least one...) is that any particular revision will not be a
complete change; some files will have been committed while others haven't yet.
But making a tag after the last file is committed would do it.
Thanks again Ben and FRuG!
- Al -
--
-- Alan Weiner -- alan@ajw.com -- http://www.ajw.com
Palm OS Certified Developer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Re: can I insert older versions of files? i.e. "here's backups of 3 months ago - put 'em in right revision order..."
Posted by FRuG FoREST <fr...@gmail.com>.
Per: Submission of older files into the REPOS, retain older date
On Sat, 17 Jul 2004 08:45:50 -0500, Ben Collins-Sussman
<su...@collab.net> wrote:
> On Fri, 2004-07-16 at 22:30, Alan Jay Weiner wrote:
>
> > Maybe it's not worth it, but if it's possible to do, I'd really like to.
>
> It's not possible to do what you want. The only thing you can do is
> what the rest of us have done:
Actually, I just posed a similar question last week. I'll summarize
what I have figured out so far....
BACKGROUND NOTES:
1) After importing the files into the REPOS, they'll have the 'current
date/time' as the file date.
2) When you 'export/checkout' the files, they'll have have "today's"
date/time.
3) You can retain original date/times, by turning on the
'~/.subversion/config' option 'use-commit-times=yes'.
4) You can turn on 'use-commit-times' globally for the whole system.
(on the system that you are checking out files, /etc/subversion/config)
SOLUTIONS:
Here's two solutions . . . based on feedback from the 'Subversion
Users' list and some of my own ideas:
1) Use the 'svn:date' property to set the file date. [1]
(I'm currently experimenting with a script to restore the dates
after import)
2) Dump the entire REPOS, then 'by a script' modify the commit times
in that file for each
file based on original files-date/times. Then re-import into a new REPOS.
Neither one is 'elegant' nor clean.
FEATURE REQUEST:
Ability to 1) Import or 2) Check-in , with SVN and retain the file
dates, per option '--retain-file-dates' (or something like that). :)
Thanks,
-FRuG
Notes:
[1] Original message:
------------------------------------------------------------------------------------------------
Ben Collins-Sussman <su...@collab.net> Fri, 09 Jul 2004 19:50:43 -0500
Here's a possible trick:
Organize your files into buckets, categorized by original dates. Then
commit each "bucket" of files in chronological order. This results in a
bunch of revisions in the repository. Then you can tweak each
revision's 'svn:date' property, so it *appears* that each bucket of
files was committed on a certain date.
In other words, because a revision's svn:date property is tweakable, you
can make the "commit times" of the files match the original times.
------------------------------------------------------------------------------------------------
[2]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: can I insert older versions of files? i.e. "here's backups of 3 months ago - put 'em in right revision order..."
Posted by Max Bowsher <ma...@ukf.net>.
Alan Jay Weiner wrote:
>>> 2) A bigger issue would be directory-comparison utilities - if the size
>>> (snip)
>>
>> Please, be aware the "use-commit-times" essentially breaks make and
similar
>> utilities.
>>
>> There is a reason why its not on by default.
>
> y'know, I didn't even think of that! Won't affect me right now 'cause my
> active projects are just me. I'll turn it off as soon as I get
everything
> into Subversion.
Um? Why as soon as you get everything into subversion?
Its a local config option, it doesn't affect the repository.
>>>>> I could simulate this by committing each file individually; that would
>>>>> (snip)
>>
>> Hmm, seems a lot of work, and is essentially fighting against subversion.
>> I have an alternate suggestion:
>> 1 old commit == 1 svn commit, but set a property on files to record their
>> actual old timestamp. The property won't mean anything special to
>> subversion, of course, but the information will be preserved, and it
should
>> be easy to write a script to recurse over a WC, doing "svn propget;
touch"
>> if ever necessary.
>
> Ah! much better! Thanks for suggesting it!
You're welcome!
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: can I insert older versions of files? i.e. "here's backups of 3 months ago - put 'em in right revision order..."
Posted by Alan Jay Weiner <al...@ajw.com>.
>> with Subversion and TortoiseSVN... (yeah, mostly procrastination... :)
>
>Ahh, procratination. A process I am very familiar with :-)
Alas, me too... :)
>>>> Am I correct in thinking that Subversion doesn't maintain a timestamp
>>>> for each file?
>> (snip)
>> 1) Sometimes multiple developers will need to compare files - often it's
>> "what's the timestamp on foo.c..." - as far as I can see it's just as
>easy
>> to say "what's the version number on foo.c..." - and with TSVN's ability
>to
>> show the version in Windows Explorer, this seems a minor issue to me...
>
>Right! And it's easier to remember a revnum, than to remember all the
>elements of a date&time.
>Also, one revnum identifies all the files in a multi-file commit.
It's usually when I'm across the room and yelling out "My foo.c is 1/1/04;
what's yours?"...
Or like right now, where I've got several projects with *some* common files (but
copied into the project; not referencing up-and-down outside directories; so I
can zip the project and send to a client as-is)
I've been lazy and edited some of the common files and added new ones; now I'm
merging back into my common library...
(damn! I want that SS-like shared files! svn:externals with a single file
instead of a directory... I need it! I use it all the time!! :)
>> 2) A bigger issue would be directory-comparison utilities - if the size
(snip)
>
>Please, be aware the "use-commit-times" essentially breaks make and similar
>utilities.
>
>There is a reason why its not on by default.
y'know, I didn't even think of that! Won't affect me right now 'cause my
active projects are just me. I'll turn it off as soon as I get everything
into Subversion.
>>>> I could simulate this by committing each file individually; that would
(snip)
>
>Hmm, seems a lot of work, and is essentially fighting against subversion.
>I have an alternate suggestion:
>1 old commit == 1 svn commit, but set a property on files to record their
>actual old timestamp. The property won't mean anything special to
>subversion, of course, but the information will be preserved, and it should
>be easy to write a script to recurse over a WC, doing "svn propget; touch"
>if ever necessary.
Ah! much better! Thanks for suggesting it!
- Al -
--
-- Alan Weiner -- alan@ajw.com -- http://www.ajw.com
Palm OS Certified Developer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: can I insert older versions of files? i.e. "here's backups of 3 months ago - put 'em in right revision order..."
Posted by Max Bowsher <ma...@ukf.net>.
Alan Jay Weiner wrote:
> My apologies for taking so long to answer... procrastination and playing
> with Subversion and TortoiseSVN... (yeah, mostly procrastination... :)
Ahh, procratination. A process I am very familiar with :-)
>>> Am I correct in thinking that Subversion doesn't maintain a timestamp
for
>>> each file?
> (snip)
>
>> Entirely correct. The theory is that the important time is the time when
the
>> changes are committed into the repository, not whenever the changes
happened
>> to be made in a working copy. This makes complete sense for the primary
>> intended use of subversion - source code control. It would be interesting
to
>> hear the details of why this isn't ideal for your application of
subversion.
>
> Mostly it's the way I've worked for years - file timestamps are
meaningful...
>
> I don't mind changing my mindset (well, ok, I'm rigid and ornery, but at
least
> for the way Subversion works with timestamps I can change... :)
> Although I wouldn't be surprised if other people don't like it either...
>
> The examples I can think of are:
>
> 1) Sometimes multiple developers will need to compare files - often it's
> "what's the timestamp on foo.c..." - as far as I can see it's just as
easy
> to say "what's the version number on foo.c..." - and with TSVN's ability
to
> show the version in Windows Explorer, this seems a minor issue to me...
Right! And it's easier to remember a revnum, than to remember all the
elements of a date&time.
Also, one revnum identifies all the files in a multi-file commit.
> 2) A bigger issue would be directory-comparison utilities - if the size
and
> timestamp are the same, the files (probably) are also. When working with
> lots of files, it saves comparing the contents...
Interesting... in what scenarios do you compare? Note that "svn diff" is
optimized along those lines.
> If Subversion's set to "use last commit date" when files are
> checked-out/exported, then such utilities will still work right with any
files
> from Subversion; e.g., comparing "this" work directory with "that" work
> directory...
> But comparing to an older backup would require comparing contents.
Please, be aware the "use-commit-times" essentially breaks make and similar
utilities.
There is a reason why its not on by default.
>>> I could simulate this by committing each file individually; that would
>>> (snip)
>
>> The downside is you have a mass of revisions that would be very hard to
>> navigate when you *do* want to look back through them.
>>
>> Also, "svn log" doesn't show you the source of copies - i.e. in "svn log
>> .../trunk" you don't see tags - you have to look at the tag itself, see
what
>> revnum it originates from and correlate that with the log of trunk.
>> Yes, this is annoying.
>
> To emulate what I've done in the past that'd be fine - trunk would always
be
> most-recent, and tags are the equivalent of my daily/milestone backups -
so
> (starting from an up-to-date working copy; i.e., matches the trunk) I'd
make
> my changes, then commit each file I changed, then tag the mess. *Not*
worth
> it (unless it were automated) for future work, but it'd keep my CDROM
backups
> and their corresponding files in the repository with matching timestamps.
Hmm, seems a lot of work, and is essentially fighting against subversion.
I have an alternate suggestion:
1 old commit == 1 svn commit, but set a property on files to record their
actual old timestamp. The property won't mean anything special to
subversion, of course, but the information will be preserved, and it should
be easy to write a script to recurse over a WC, doing "svn propget; touch"
if ever necessary.
> Branches and tags are one of the things I really *don't* like about
> Subversion.. Conceptually, I like the elegance of a tag being just a
branch.
> But I have already created a tag in the trunk (oops!) and I just see
myself
> making such stupid mistakes...
I hated subversion's tags too when I first read about them. I'm quite
comfortable with them now, except that there is no good way to tag only
subtrees of a project.
> The biggest problem I've had is "this is how I've done it / want to do it"
and
> Subversion does things differently... I've turned into such a
curmudgeon....
> :)
>
> Overall I like Subversion a lot, and I expect that as more use it, it will
> just get better and better. And the more I use it the more the way it
works
> will be "the way *I* work"
:-)
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: can I insert older versions of files? i.e. "here's backups of 3 months ago - put 'em in right revision order..."
Posted by Alan Jay Weiner <al...@ajw.com>.
My apologies for taking so long to answer... procrastination and playing with
Subversion and TortoiseSVN... (yeah, mostly procrastination... :)
>> Am I correct in thinking that Subversion doesn't maintain a timestamp for
>>each file?
(snip)
>Entirely correct. The theory is that the important time is the time when the
>changes are committed into the repository, not whenever the changes happened
>to be made in a working copy. This makes complete sense for the primary
>intended use of subversion - source code control. It would be interesting to
>hear the details of why this isn't ideal for your application of subversion.
Mostly it's the way I've worked for years - file timestamps are meaningful...
I don't mind changing my mindset (well, ok, I'm rigid and ornery, but at least
for the way Subversion works with timestamps I can change... :)
Although I wouldn't be surprised if other people don't like it either...
The examples I can think of are:
1) Sometimes multiple developers will need to compare files - often it's
"what's the timestamp on foo.c..." - as far as I can see it's just as easy to
say "what's the version number on foo.c..." - and with TSVN's ability to show
the version in Windows Explorer, this seems a minor issue to me...
2) A bigger issue would be directory-comparison utilities - if the size and
timestamp are the same, the files (probably) are also. When working with lots
of files, it saves comparing the contents...
If Subversion's set to "use last commit date" when files are
checked-out/exported, then such utilities will still work right with any files
from Subversion; e.g., comparing "this" work directory with "that" work
directory...
But comparing to an older backup would require comparing contents.
3) "We've always done it that way" :)
None are compelling enough for me not to use Subversion going forward.
>> I could simulate this by committing each file individually; that would
(snip)
>The downside is you have a mass of revisions that would be very hard to
>navigate when you *do* want to look back through them.
>
>Also, "svn log" doesn't show you the source of copies - i.e. in "svn log
>.../trunk" you don't see tags - you have to look at the tag itself, see what
>revnum it originates from and correlate that with the log of trunk.
>Yes, this is annoying.
To emulate what I've done in the past that'd be fine - trunk would always be
most-recent, and tags are the equivalent of my daily/milestone backups - so
(starting from an up-to-date working copy; i.e., matches the trunk) I'd make my
changes, then commit each file I changed, then tag the mess. *Not* worth it
(unless it were automated) for future work, but it'd keep my CDROM backups and
their corresponding files in the repository with matching timestamps.
Branches and tags are one of the things I really *don't* like about Subversion..
Conceptually, I like the elegance of a tag being just a branch. But I have
already created a tag in the trunk (oops!) and I just see myself making such
stupid mistakes...
(I've already submitted a suggestion for TortoiseSVN to make branching/tagging
more convenient/less errorprone/more the way *I* want it... :) Basically
just abstracting away from the project/trunk vs. project/tag path; TSVN would
put the correct path for "this project's tag" or "this project's branches" and
the user would check-box "making a tag" or "making a branch". If it were in
Subversion itself, then when the project is imported, it would/could be
configured to know "trunk for projectX is projectX/trunk, branches go in
projectX/branches, and tags go in projectX/tags" and then URLs could be
project-root and function based... Of course, the way it is now "just works"
which really *is* neat - but uses [meaning *me!*] make mistakes...)
The biggest problem I've had is "this is how I've done it / want to do it" and
Subversion does things differently... I've turned into such a curmudgeon....
:)
Overall I like Subversion a lot, and I expect that as more use it, it will just
get better and better. And the more I use it the more the way it works will be
"the way *I* work"
- Al -
--
-- Alan Weiner -- alan@ajw.com -- http://www.ajw.com
Palm OS Certified Developer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: can I insert older versions of files? i.e. "here's backups of 3 months ago - put 'em in right revision order..."
Posted by Max Bowsher <ma...@ukf.net>.
Alan Jay Weiner wrote:
> Am I correct in thinking that Subversion doesn't maintain a timestamp for
each
> file? That when checked out ("Switch" or "Update" commands) they will be
set
> to either the current time or the time of the last commit? (depending on
the
> setting of "use-commit-times")
>
> (this, btw, is one thing I *don't* like about Subversion - I'd much rather
the
> file information stayed with the file... Although I can understand the
> reasoning... I did try changing svn:date on revisions and that worked;
I
> couldn't do it on individual files though - am I right in thinking there
> isn't a way to have different timestamps on files within a single
revision?)
Entirely correct. The theory is that the important time is the time when the
changes are committed into the repository, not whenever the changes happened
to be made in a working copy. This makes complete sense for the primary
intended use of subversion - source code control. It would be interesting to
hear the details of why this isn't ideal for your application of subversion.
> I could simulate this by committing each file individually; that would
create
> revisions for each file, and I could set the svn:date for each revision to
the
> date that I wanted that file to be. This would create a huge number of
> revisions, but I'd get timestamps that would match my CDROM backups...
>
> Is there a downside to doing this? Not sure if I will - realistically,
I
> almost never go back more than a few revisions and this sounds like more
work
> than I want to do... But conceptually, this'd work, right?
>
> Essentially, sort all the files (within a backup) by date, commit them
> individually, and then create a tag to mark that backup's point in time.
> Then repeat for each backup in sequence...
The downside is you have a mass of revisions that would be very hard to
navigate when you *do* want to look back through them.
Also, "svn log" doesn't show you the source of copies - i.e. in "svn log
.../trunk" you don't see tags - you have to look at the tag itself, see what
revnum it originates from and correlate that with the log of trunk.
Yes, this is annoying.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: can I insert older versions of files? i.e. "here's backups of 3 months ago - put 'em in right revision order..."
Posted by Alan Jay Weiner <al...@ajw.com>.
>It's not possible to do what you want. The only thing you can do is
>what the rest of us have done:
>
>1. import a snapshot of an initial tree
>2. checkout a working copy
>3. unpack a new tree snapshot on top of the working copy
>4. adjust working copy as needed
>5. commit
>6. goto step 3
>
>Sorry. :-(
Thanks for the reply, Ben!
I tried doing that last night with one project; it wasn't as bad as I thought it
would be - only had a dozen or so backups for that project and rolled 'em all
into Subversion in less than an hour.
I've typed the detailed instructions below for anyone interested.
I do have some questions though... (well, lots, but I'll only ask a couple
here... :)
Am I correct in thinking that Subversion doesn't maintain a timestamp for each
file? That when checked out ("Switch" or "Update" commands) they will be set
to either the current time or the time of the last commit? (depending on the
setting of "use-commit-times")
(this, btw, is one thing I *don't* like about Subversion - I'd much rather the
file information stayed with the file... Although I can understand the
reasoning... I did try changing svn:date on revisions and that worked; I
couldn't do it on individual files though - am I right in thinking there isn't a
way to have different timestamps on files within a single revision?)
I could simulate this by committing each file individually; that would create
revisions for each file, and I could set the svn:date for each revision to the
date that I wanted that file to be. This would create a huge number of
revisions, but I'd get timestamps that would match my CDROM backups...
Is there a downside to doing this? Not sure if I will - realistically, I
almost never go back more than a few revisions and this sounds like more work
than I want to do... But conceptually, this'd work, right?
Essentially, sort all the files (within a backup) by date, commit them
individually, and then create a tag to mark that backup's point in time. Then
repeat for each backup in sequence...
I have more comments about changing svn:date, etc - I'll attach them to FRuG's
message as they're extensions to his comments...
Thanks again, Ben!
- Al -
(details of rolling my CDROM backups into Subversion...)
I'm using Windows 2000, Subversion is loaded on my notebook and running in a DOS
box (eventually I'll run it as a service using FireDaemon) and I'm using
TortoiseSVN as a GUI client.
I created the recommended "trunk", "tags", and "branches" directories in a
temporary directory:
temp\projectname\branches
temp\projectname\tags
temp\projectname\trunk
I started with my oldest backup, copied it into temp\projectname\trunk, and then
"cleaned" it - removed all the intermediate files and anything I didn't want.
Then I right-clicked the temp directory and selected TortoiseSVN "Import" - that
imports everything within the temp directory. If you click on
temp\projectname, you'll just import branches, tags, and trunk... did that the
first time... :)
(hereafter, TortoiseSVN commands will be "TSVN <command>")
TSVN Branch/Tags and created a tag in projectname\tags.
Then simply copy the entire next backup on top of the temp\projectname\trunk -
this overwrites the initial import (into repository) files in your temp ("local
work") directory. No need to clean intermediate files again.
Right-click on temp\projectname\trunk and TSVN Commit. This brings up a dialog
("Enter Log Message") showing all the files. Be sure "Show unversioned files"
is selected so you'll see any newly-added files. (files added between last
backup and this backup). If there are any new files that should be added to
the repository, check the box next to them. Then click OK to commit those
changed files.
Then TSVN Branch/Tags again and create a new tag to identify that backup point.
Repeat for all your backups.
This works well for rolling everything into Subversion; you'll see new files
pretty easily, so you're unlikely to miss adding them to the repository.
It does *not* show deleted files as readily though. (those files deleted
between two backups). You'll have to check manually for that.
This ends up with a series of tags ("branches" in the tags directory) like this:
projectname\tags\040110
projectname\tags\040205
projectname\tags\040207
projectname\tags\040323
projectname\tags\040325_beta_1
etc etc.
The name of the tag is of your choosing, of course - I've been in the habit of
marking things with yymmdd for a long time... (or yymmdd_hhmm if necessary)
I like how it sorts automatically into date order...
NOTE: in truth, you don't really need to make the tags - I did because I wanted
to be able to match my backup to a particular CDROM backup.
Each time you do the TSVN Commit, Subversion creates a revision - you can use
that revision as the "stable points" if you want. Making a tag allows you to
name it something more reasonable - like "Release Candidate 1" etc.
(end of sidebar...) -=-=-=-=-=-=-=-=-=-=-
--
-- Alan Weiner -- alan@ajw.com -- http://www.ajw.com
Palm OS Certified Developer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org