hgsubversion | 17 Sep 17:26 2014

8 new revisions pushed by durin42 on 2014-09-17 15:26 GMT

8 new revisions:

Revision: 4ed0855d211f
Branch:   default
Author:   Siddharth Agarwal <sid0@...>
Date:     Tue Sep 16 23:42:57 2014 UTC
Log:      compathacks: add hacks for filectxfn deletion contract changing...
https://code.google.com/p/hgsubversion/source/detail?r=4ed0855d211f

Revision: 339b5703000c
Branch:   default
Author:   Siddharth Agarwal <sid0@...>
Date:     Tue Sep 16 23:02:44 2014 UTC
Log:      test_util: use compat hack for filectxfn for deleted files
https://code.google.com/p/hgsubversion/source/detail?r=339b5703000c

Revision: f96e2495de39
Branch:   default
Author:   Siddharth Agarwal <sid0@...>
Date:     Tue Sep 16 23:03:31 2014 UTC
Log:      test_push_command: use compat hack for filectxfn for deleted files
https://code.google.com/p/hgsubversion/source/detail?r=f96e2495de39

Revision: 57000c9b53f1
Branch:   default
Author:   Siddharth Agarwal <sid0@...>
Date:     Tue Sep 16 23:15:17 2014 UTC
Log:      stupid: in diff_branchrev, use compat hack for filectxfn for  
deleted f...
https://code.google.com/p/hgsubversion/source/detail?r=57000c9b53f1
(Continue reading)

Siddharth Agarwal | 17 Sep 04:37 2014

[PATCH 1 of 7] compathacks: add hacks for filectxfn deletion contract changing

# HG changeset patch
# User Siddharth Agarwal <sid0@...>
# Date 1410910977 25200
#      Tue Sep 16 16:42:57 2014 -0700
# Node ID ad69553db33c53309604db0822c5d2882d674fc6
# Parent  aa8b72bd1320a4a339fb2b43868df520edce7528
compathacks: add hacks for filectxfn deletion contract changing

Mercurial rev 650b5b6e75ed changed the contract for filectxfn, and rev
d226fe36e362 added a way for us to detect the change.

diff --git a/hgsubversion/compathacks.py b/hgsubversion/compathacks.py
--- a/hgsubversion/compathacks.py
+++ b/hgsubversion/compathacks.py
 <at>  <at>  -1,5 +1,7  <at>  <at> 
 """Functions to work around API changes."""

+import errno
+import sys

 def branchset(repo):
     """Return the set of branches present in a repo.
 <at>  <at>  -26,3 +28,42  <at>  <at> 
         return context.memfilectx(repo, path, data, islink, isexec, copied)
     except TypeError:
         return context.memfilectx(path, data, islink, isexec, copied)
+
+def filectxfn_deleted(memctx, path):
+    """
+    Return None or raise an IOError as necessary if path is deleted.
(Continue reading)

Sean Farley | 9 Sep 06:52 2014
Picon

[PATCH] replay: fix filectxfn compatibility with hg's default branch

# HG changeset patch
# User Sean Farley <sean.michael.farley@...>
# Date 1410238255 25200
#      Mon Sep 08 21:50:55 2014 -0700
# Node ID f808ba27ca48fac8bd0c4e1c346f548efeee9a76
# Parent  f367a446219118983319055ceba06daac4566252
replay: fix filectxfn compatibility with hg's default branch

Mercurial rev 650b5b6e75ed changed the contract for filectxfn, and rev
d226fe36e362 added a way for us to detect the change.

diff --git a/hgsubversion/replay.py b/hgsubversion/replay.py
--- a/hgsubversion/replay.py
+++ b/hgsubversion/replay.py
 <at>  <at>  -145,11 +145,16  <at>  <at>  def _convert_rev(ui, meta, svn, r, tbdel
             extra.update({'branch': parentctx.extra().get('branch', None),
                           'close': 1})

         def filectxfn(repo, memctx, path):
             current_file = files[path]
-            data, isexec, islink, copied = current.pop(current_file)
+            try:
+                data, isexec, islink, copied = current.pop(current_file)
+            except IOError, e:
+                if getattr(context.memctx, '_returnnoneformissingfiles', False):
+                    return None
+                raise e
             if isexec is None or islink is None:
                 flags = parentctx.flags(path)
                 if isexec is None:
(Continue reading)

hgsubversion | 31 Aug 16:04 2014

5 new revisions pushed by durin42 on 2014-08-31 14:03 GMT

5 new revisions:

Revision: ba8485b9fee0
Branch:   default
Author:   David Schleimer <dschleimer@...>
Date:     Sun Nov 17 17:57:00 2013 UTC
Log:      editor: correctly import copies of directories from non-tracked  
or clo...
https://code.google.com/p/hgsubversion/source/detail?r=ba8485b9fee0

Revision: 0d0132cba155
Branch:   default
Author:   David Schleimer <dschleimer@...>
Date:     Tue Apr  8 00:51:59 2014 UTC
Log:      editor: fix edge case with in memory file-store size limit...
https://code.google.com/p/hgsubversion/source/detail?r=0d0132cba155

Revision: d3c79072bc6a
Branch:   default
Author:   David Schleimer <dschleimer@...>
Date:     Tue Apr  8 01:28:35 2014 UTC
Log:      editor: correctly import symlink copy+modify with non-empty  
prefix...
https://code.google.com/p/hgsubversion/source/detail?r=d3c79072bc6a

Revision: 6b15eeb78c1a
Branch:   default
Author:   David Schleimer <dschleimer@...>
Date:     Tue Apr  8 01:44:46 2014 UTC
Log:      editor: fix replay handling for copied + modified symlinks...
(Continue reading)

David Schleimer | 30 Aug 18:23 2014

[PATCH] push: update to branch tip instead of tip

# HG changeset patch
# User David Schleimer <dschleimer@...>
# Date 1409415811 25200
#      Sat Aug 30 09:23:31 2014 -0700
# Node ID cd3dc5d99e6eefaec9ab52de1fb829351a3dec74
# Parent  5c29173759610c399c6982b7fb6645931aa50b5d
push: update to branch tip instead of tip

We previously updated to the repository tip after pushing a revision,
presumably on the assumption that tip would be the last revision we
just pushed.  This assumption is flawed for high traffic repositories.
In particular, you previsouly would sometimes end up on a completley
unrelated commit if someone else commits to a different branch in
between the time we push a revision and pull it back from the server.

This changes to instead update to the branch tip of the branch we were
on at the beginning of the push.  This should be either the revision
we just pushed or a linear descendent of the revision we just pushed,
with a fair degree of reliability.

diff --git a/hgsubversion/wrappers.py b/hgsubversion/wrappers.py
--- a/hgsubversion/wrappers.py
+++ b/hgsubversion/wrappers.py
 <at>  <at>  -210,6 +210,7  <at>  <at> 
             ui.status('Cowardly refusing to push branch merge\n')
             return 0 # results in nonzero exit status, see hg's commands.py
         workingrev = repo.parents()[0]
+        workingbranch = workingrev.branch()
         ui.status('searching for changes\n')
         hashes = meta.revmap.hashes()
(Continue reading)

David Schleimer | 29 Aug 18:34 2014

RE: [PATCH 1 of 4] editor: correctly import copies of directories from non-tracked or closed branches

For whatever reason the original of this isn't making it outside the FB network.  You can pull this series
from https://dschleimer-HWgY0/vhk/IBXFe83j6qeQ <at> public.gmane.org/dschleimer/hgsubversion#6b15eeb78c1a

> -----Original Message-----
> From: David Schleimer [mailto:dschleimer@...]
> Sent: Friday, August 29, 2014 6:27 PM
> To: raf@...
> Cc: hgsubversion@...
> Subject: [PATCH 1 of 4] editor: correctly import copies of directories from
> non-tracked or closed branches
> 
> # HG changeset patch
> # User David Schleimer <dschleimer@...> # Date 1384711020 28800
> #      Sun Nov 17 09:57:00 2013 -0800
> # Node ID ba8485b9fee0d244d124812a457fb0ced8821af8
> # Parent  5c29173759610c399c6982b7fb6645931aa50b5d
> editor: correctly import copies of directories from non-tracked or closed
> branches
> 
> diff --git a/hgsubversion/editor.py b/hgsubversion/editor.py
> --- a/hgsubversion/editor.py
> +++ b/hgsubversion/editor.py
>  <at>  <at>  -239,6 +239,13  <at>  <at> 
>          else:
>              # Resolve missing directories content immediately so the
>              # missing files maybe processed by delete actions.
> +            # we remove the missing directory entries to deal with the case
> +            # where a directory is replaced from e.g. a closed branch
> +            # this will show up as a delete and then a copy
> +            # we process deletes after missing, so we can handle a directory
(Continue reading)

David Schleimer | 29 Aug 17:55 2014

[PATCH 4 of 4] editor: fix replay handling for copied + modified symlinks

# HG changeset patch
# User David Schleimer <dschleimer@...>
# Date 1396921486 25200
#      Mon Apr 07 18:44:46 2014 -0700
# Node ID 6b15eeb78c1a502f4a7ba7e2b18c290dba37ac8f
# Parent  d3c79072bc6ab856245183b6040e3878370a0c3e
editor: fix replay handling for copied + modified symlinks

We strip the 'link ' prefix from symlinks when we store it in
Mercurial.  We reapply it when we start editing the file via
open_file, but not via add_file.  this means that modified symlniks
would replay correctly, but not copied and modified symlinks.  This
corrects that ommission.

diff --git a/hgsubversion/editor.py b/hgsubversion/editor.py
--- a/hgsubversion/editor.py
+++ b/hgsubversion/editor.py
 <at>  <at>  -380,7 +380,10  <at>  <at> 

         fctx = ctx.filectx(from_file)
         flags = fctx.flags()
-        self.current.set(path, fctx.data(), 'x' in flags, 'l' in flags)
+        base = fctx.data()
+        if 'l' in flags:
+            base = 'link ' + base
+        self.current.set(path, base, 'x' in flags, 'l' in flags)
         copypath = None
         if from_branch == branch:
             parentid = self.meta.get_parent_revision(
 <at>  <at>  -389,7 +392,7  <at>  <at> 
(Continue reading)

David Schleimer | 29 Aug 17:55 2014

[PATCH 3 of 4] editor: correctly import symlink copy+modify with non-empty prefix

# HG changeset patch
# User David Schleimer <dschleimer@...>
# Date 1396920515 25200
#      Mon Apr 07 18:28:35 2014 -0700
# Node ID d3c79072bc6ab856245183b6040e3878370a0c3e
# Parent  0d0132cba155b711183e3c5306fc5b22bc28dc91
editor: correctly import symlink copy+modify with non-empty prefix

We alwasy fail editing for symlinks, since we strip the leading 'link '
subversion includes when storing in mercurial, and then let svn
attempt to apply deltas against the stripped version.  This
unsurprisingly fails, and we write the resulting empty-string to the
Filestore for the current revision, and add the symlink in question to
the missing list to handle stupidly later.

Unfortunately, this would break down because editing adds files to the
store using their absolute path whereas missing files are added
relative to our subdir.  the absolut path file appears to win, which
results in us getting a symlink whose target is the empty string.

This fixes the problem by adding missing files to the fileStore using
their absolute path.

diff --git a/hgsubversion/editor.py b/hgsubversion/editor.py
--- a/hgsubversion/editor.py
+++ b/hgsubversion/editor.py
 <at>  <at>  -651,7 +651,7  <at>  <at> 
                     svn.init_ra_and_client()
                 i += 1
                 data, mode = svn.get_file(f, rev)
(Continue reading)

David Schleimer | 29 Aug 17:55 2014

[PATCH 2 of 4] editor: fix edge case with in memory file-store size limit

# HG changeset patch
# User David Schleimer <dschleimer@...>
# Date 1396918319 25200
#      Mon Apr 07 17:51:59 2014 -0700
# Node ID 0d0132cba155b711183e3c5306fc5b22bc28dc91
# Parent  ba8485b9fee0d244d124812a457fb0ced8821af8
editor: fix edge case with in memory file-store size limit

There are a few cases where we will set a single file into to the
editor's FileStore object more than once.  Notably, for copied and
then modified files, we will set it at least twice.  Three times if
editing fails (which it can for symlinks).

If we pass the in-memory storage limit in between the first (or second
if editing fails) time we set the file and the last time we set the
file, we will write the data to the in memory store the first time and
the file store the last time.  We didn't remove it form the in-memory
store though, and we always prefer reading from the in-memory store.
This means we can sometimes end up with the wrong version of a file.

This is fairly unlikely to happen in normal use since you need to hit
the memory limit between two writes to the store for the same file.
We only write a file multiple times if a) the file (and not one of
it's parent directories) is copied and then modified or b) editing
fails.  From what I can tell, it's only common for editing to fail for
symlinks, and they ten to be relatively small data that is unlikely to
push over the limit.  Finally, the default limit is 100MB which I
would expect to be most often either well over (source code) or well
under (binaries or automated changes) the size of the changes files in
a single commit.
(Continue reading)

hgsubversion | 12 Aug 17:09 2014

3 new revisions pushed by durin42 on 2014-08-12 15:08 GMT

3 new revisions:

Revision: 46523cdfd3b0
Branch:   stable
Author:   David Schleimer <dschleimer@...>
Date:     Fri Aug  8 02:30:26 2014 UTC
Log:      pushmod: prepend "link " to base text for links...
http://code.google.com/p/hgsubversion/source/detail?r=46523cdfd3b0

Revision: 807c443928d4
Branch:   stable
Author:   Augie Fackler <raf@...>
Date:     Tue Aug 12 15:08:09 2014 UTC
Log:      Added tag 1.6.3 for changeset 46523cdfd3b0
http://code.google.com/p/hgsubversion/source/detail?r=807c443928d4

Revision: 5c2917375961
Branch:   default
Author:   Augie Fackler <raf@...>
Date:     Tue Aug 12 15:08:41 2014 UTC
Log:      Merge with stable.
http://code.google.com/p/hgsubversion/source/detail?r=5c2917375961

==============================================================================
Revision: 46523cdfd3b0
Branch:   stable
Author:   David Schleimer <dschleimer@...>
Date:     Fri Aug  8 02:30:26 2014 UTC
Log:      pushmod: prepend "link " to base text for links

(Continue reading)

David Schleimer | 11 Aug 01:19 2014

[PATCH] pushmod: prepend "link " to base text for links

# HG changeset patch
# User David Schleimer <dschleimer@...>
# Date 1407465026 25200
#      Thu Aug 07 19:30:26 2014 -0700
# Node ID a688afa3a84c1a84b91fbe8c6254b890fbabe037
# Parent  9490a30529358456e47cf7c3e1f0322ecf93724e
pushmod: prepend "link " to base text for links

http://svn.apache.org/viewvc?view=revision&revision=1223036 exposes
what is arguably a bug in hgsubversion push code.  Specifically, when
we are receiving text from the server in an editor, we prepend a "link
" to the text of symlinks when opening a file and strip it when
closing a file.  We don't, however, prepend "link " to the base we use
when sending text changes to the server.

This was working before because prior to that revision, the first
thing subversion did was to check whether the entirety of the before
text or the entirety of the after text was less than 64 bytes.  In
that case, it just sent the entirety of the after text as a single
insert operation.  I'd expect most, but not all symlinks to fit under
the 64 byte limit, including the leading "link " text on the
subversion end.

After the change, the first thing subversion does is check for a
leading match that is more than 4 bytes long, or that is the full
length of the after text.  In this case, it sends a copy operation for
the leading match, and then goes into the if < 64 bytes remaining send
the whole thing behavior.  It also looks for trailing matches of more
than 4 bytes even in the <64 byte case, but that's not what breaks the
tests.
(Continue reading)


Gmane