Due to the recent increase in activity on this project, I have opened up
the Trac site a bit to allow anonymous users to modify and create wiki
pages, as well as create or append to tickets (but not otherwise modify
tickets).
I have avoided this in the past because unfortunately a lot of lazy
Kenneth Porter wrote:
On Wednesday, February 07, 2007 11:56 AM + Jonathan Perret
<[EMAIL PROTECTED]> wrote:
Perhaps the vss2svn wiki should contain information of this kind ?
Sounds like a good idea.
I did something like that, but my conversion was on a Linux box. I
didn't have access
On Wednesday, February 07, 2007 11:56 AM + Jonathan Perret
<[EMAIL PROTECTED]> wrote:
Perhaps the vss2svn wiki should contain information of this kind ?
Sounds like a good idea.
I did something like that, but my conversion was on a Linux box. I didn't
have access to the customer's VSS s
I will try the patch and see if it fixes. Thanks.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Dirk
> Sent: Wednesday, February 07, 2007 2:40 PM
> To: Vss2Svn Users
> Subject: Re: Invalid change ordering?
>
>
> >
> > Thanks for the output. S
Applause. This is very good overview for all newcomers and also a
detailed description. If I only could write technical documentation in
English like this, I wouldn't be that lazy doing it.
Thanks, I will add it to the WIKI.
Dirk
Jonathan Perret schrieb:
Regarding the "live" database, you ca
Thanks for the output. Stephen pointed me into the correct direction.
The problem is a delete/share cycle.
I was now able to write a test scenario for this and attached is a patch
that will solve this problem. Could you please try it out?
Best regards
Dirk
Index: Vss2Svn/ActionHandler.pm
D:\test>svn ci -mtest
Replacing test\test1.txt
Upps, ok. But isn't this a special case that a delete/add is treated as
one action replace? Would be interesting how this comes out in the
dumpfile. Because we can not easily do such a "join".
Dirk
_
Dirk wrote:
1.) You can not do a delete and a copy-from the same revision in one
revision
Unless I misunderstood what you're saying there, you certainly can:
D:\test>svn del test1.txt
D test1.txt
D:\test>svn copy test1.txt -r HEAD test1.txt
A test1.txt
D:\test>svn status
R
Even if an item is deleted, surely it is still a valid source for the
revisions of the file to date... i.e. until the file is next updated,
it would presumably continue to be a valid share source for the
current revision of the file.
Isn't that how a delete/recover cycle works too?
Yes, t
Dirk wrote:
You can see that the file is deleted from LABA and later shared
there again. But the itempathes generated for the share source is the
same as the share target. Consequently it will share from itself. The
reason is, that the function "_get_valid_path" does not honor the
{deleted}
Hello Scott
Here is the section for 2750 and following it the only previous
occurance of the file in 2635.
Thanks for the output. Stephen pointed me into the correct direction.
The problem is a delete/share cycle. This will screw up the converter
and I think, I also know why. Here is the
> Can you please post the content of the dumpfile at revision
> 2750 to verify that each copy-from revision lists the same number?
>
>
> Dirk
>
Here is the section for 2750 and following it the only previous
occurance of the file in 2635.
Scott
Revision-number: 2750
Prop-content-length: 1
Jonathan Perret wrote:
Hello,
Below is a one-line patch to vss2svn.pl that makes the
script's standard output hot (unbuffered).
As I mentioned in my last message (Suggested vss2svn workflow)
I think vss2svn should always be run with the output
(both STDOUT and STDERR) directed to a file. Unfort
Wow! I'm going to have to hire an IT person.
Your procedure sure makes sense though. Thanks.
Scott
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Jonathan Perret
> Sent: Wednesday, February 07, 2007 4:57 AM
> To: Vss2Svn Users
> Subject: Su
Hello again,
This is another one-line patch that "handles" VSS labels that
contain forward slashes. We had a few instances of labels that
went "What we deployed on 13/4/2001" and this resulted in
vss2svn creating "/labels/What we deployed on 13",
with a "4" subdirectory and then a "2001" subdirect
Hello,
Below is a one-line patch to vss2svn.pl that makes the
script's standard output hot (unbuffered).
As I mentioned in my last message (Suggested vss2svn workflow)
I think vss2svn should always be run with the output
(both STDOUT and STDERR) directed to a file. Unfortunately
by default this l
Firstly, I'm running the nightly (6-Feb-2007) that Tody patched to solve an
'Inconsistent item type' error.
Unfortunately the dumpfile has an error when I try to import it.
--- Committed revision 4528 >>>
<<< Started new transaction, based on original revision 4529
* editing path : orph
> Regarding the "live" database, you can simply make a file copy of the
> VSS files to your local computer and run the conversion from there. If
> you do it in a silent minute, during the night, you could probaply get
> a pristine copy.
Definitely ! A copy of the database should be the first thing
Arrrgh, why has nobody pointed out, that the file is "copied" twice ;-).
Naturally that's the problem.
Since I have the converter output here in a private copy, I followed
this file throughout the history, and it seems, that problems start
after a delete while the file is in the orphan cache.
Scott Nowell wrote:
<<< Started new transaction, based on original revision 2750
* adding path : labels/Ready for MS01 Validation Run ... done.
* adding path : labels/Ready for MS01 Validation Run/UC00 ... done.
* adding path : labels/Ready for MS01 Validation Run/UC00/Source
...
for all others, that not took part in our private mail thread. My guess
for the reason for the problem are mixed copy-from revisions in a
labeling situation. That means, that we wanted to copy file labels
within one revision, where the copy-from revision was not the same.
Therefor I made a patc
21 matches
Mail list logo
