IB> * I think git-svn doesn't handle the case, when a tag is deleted.
IB> I expected it to rename the ref from "tags/tagname" to
IB> "tags/tagname@rev", but that doesn't happen.
IB> If a tag is replaced, there's no way to tell what was the previous
IB> state of that tag: git-svn just rewrit
Ilya Basin wrote:
> Hi Eric. I'm out of spare time and I still unable to import my repo.
> The code of SVN.pm is too complex. Please help me.
Sorry, most what I do nowadays for git-svn is ACK/NACK changes.
git-svn has made itself obsolete for most contributors, myself included;
so it's hard for
Hi Eric. I'm out of spare time and I still unable to import my repo.
The code of SVN.pm is too complex. Please help me.
Here's the list of my issues:
* I think git-svn doesn't handle the case, when a tag is deleted.
I expected it to rename the ref from "tags/tagname" to
"tags/tagname@rev", but
The last error I encountered is:
r7009 = 39805bb078983e34f2fc8d2c8c02d695d00d11c0 (refs/remotes/DMC4_Basic)
Too many open files: Can't open file
'/home/il/builds/sicap/gitsvn/prd_dmc4.svn/db/revs/0/786': Too many open
files at
/.snapshots/persist/builds/git/git-git/
EW>> Ilya Basin wrote:
>>> Hi. I won't send you updated patches until I import and test my huge
>>> repo. Everything will be here:
>>> https://github.com/basinilya/git/commits/v1.8.2.2-git-svn-fixes
>>>
>>> At the moment I've decided not to implement the Junio's proposal:
>>> > >> JCH> comment li
EW> Ilya Basin wrote:
>> Hi. I won't send you updated patches until I import and test my huge
>> repo. Everything will be here:
>> https://github.com/basinilya/git/commits/v1.8.2.2-git-svn-fixes
>>
>> At the moment I've decided not to implement the Junio's proposal:
>> > >> JCH> comment line "# a
Ilya Basin wrote:
> Hi. I won't send you updated patches until I import and test my huge
> repo. Everything will be here:
> https://github.com/basinilya/git/commits/v1.8.2.2-git-svn-fixes
>
> At the moment I've decided not to implement the Junio's proposal:
> > >> JCH> comment line "# added by gi
Ilya Basin wrote:
> EW> My personal philosophy has always been: git svn users should leave
> EW> no trace or indication they're using a non-standard SVN client.
>
> Placeholders aren't pushed back to svn.
Right, I was confused, as I often am :x
--
To unsubscribe from this list: send the line "un
On Wed, May 1, 2013 at 10:49 PM, Eric Wong wrote:
> Junio C Hamano wrote:
>
>> Eric Wong writes:
>
>> That however is not a property of the directory containing it (or
>> the path to that .gitignore file) that is valid throughout the
>> history of the project. It is a property of a specific tre
Hi. I won't send you updated patches until I import and test my huge
repo. Everything will be here:
https://github.com/basinilya/git/commits/v1.8.2.2-git-svn-fixes
At the moment I've decided not to implement the Junio's proposal:
> >> JCH> comment line "# added by git-svn only to keep the director
EW> My personal philosophy has always been: git svn users should leave
EW> no trace or indication they're using a non-standard SVN client.
Placeholders aren't pushed back to svn.
--
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kerne
Junio C Hamano wrote:
> Eric Wong writes:
> > Ilya Basin wrote:
> >> JCH> comment line "# added by git-svn only to keep the directory" and
> >> JCH> consider a directory that has nothing but .gitignore that consists
> >> JCH> of only that exact comment line an "added placeholder" directory to
>
Eric Wong writes:
> Ilya Basin wrote:
>> JCH> comment line "# added by git-svn only to keep the directory" and
>> JCH> consider a directory that has nothing but .gitignore that consists
>> JCH> of only that exact comment line an "added placeholder" directory to
>> JCH> work it around.
>> Sounds
Ilya Basin wrote:
> JCH> comment line "# added by git-svn only to keep the directory" and
> JCH> consider a directory that has nothing but .gitignore that consists
> JCH> of only that exact comment line an "added placeholder" directory to
> JCH> work it around.
> Sounds good, but it's not I who de
JCH> ...and you want to perform a merge on the
JCH> Git side of that branch with another Git branch that does have real
JCH> contents in that directory, you would want the result to say "This
JCH> directory no longer is just for a placeholder", but you cannot say
JCH> that globally by updating the
Ilya Basin writes:
> IB> In my repo the placeholders change too often (in 1/4 commits). I'm
> IB> thinking of using:
> IB> 'git config --unset "svn-remote.$repo_id.added-placeholder" path_regex'
> IB> instead of full rewrite.
>
> I need your help. There are still problems:
>
> $ grep "define
IB> In my repo the placeholders change too often (in 1/4 commits). I'm
IB> thinking of using:
IB> 'git config --unset "svn-remote.$repo_id.added-placeholder" path_regex'
IB> instead of full rewrite.
I need your help. There are still problems:
$ grep "define MAX_MATCHES" ~/builds/git/git-git/c
IB> + return undef if (!keys $self->{_save_ph});
Correct is: return undef if (!keys %{$self->{_save_ph}});
In my repo the placeholders change too often (in 1/4 commits). I'm
thinking of using:
'git config --unset "svn-remote.$repo_id.added-placeholder" path_regex'
instead of full rewrite.
-
.git/config is written on each commit. It's slow
---
perl/Git/SVN/Fetcher.pm | 77 +++--
1 file changed, 49 insertions(+), 28 deletions(-)
diff --git a/perl/Git/SVN/Fetcher.pm b/perl/Git/SVN/Fetcher.pm
index e658889..a5ad4cd 100644
--- a/perl/Git/SVN/Fe
19 matches
Mail list logo
