check out everything except, '' subfolder should be shallower

[Lathan Bidwell]

Hey,

I have a subversion tree that has several sub-folders (buried deep in 
the tree) that contain large amounts of media files... mp3, m4v, 


What I am trying to do is to checkout "smaller" versions of my 
repository by setting those media folders to be --depth empty.


I have been experimenting with --set-depth immediates and such.

What I am running into, is that there is no easy way to checkout the 
repository without downloading everything. It is quite a pain to 
checkout the repository as depth empty and then try to get it back to 
depth infinity.



/(infinity)
/a(infinity)
/b(infinity)
*/b/media(empty)*
/b/regular(infinity)
/b/regular/files(infinity)
/b/regular/files/here(infinity)
/c(infinity)
/d(infinity)
*/d/media(empty)*


How can i checkout out this sample repository without downloading the 
/b/media/ and /d/media folders?


The example i have (with checking it all out first is):
svn checkout '' --depth immediates
svn update --set-depth exclude /b/media
svn update --set-depth exclude /d/media
svn update --set-depth infinity *


Perhaps I am confused, but wouldn't that last depth infinity reset the 
depth exclude from the previous lines?


Thank you for your help,

Lathan Bidwell
Andrews University

Re: check out everything except, '' subfolder should be shallower

[Lathan Bidwell]

On 01/24/2013 05:14 AM, Philip Martin wrote:

Lathan Bidwell  writes:


How can i checkout out this sample repository without downloading the /b/media/ 
and /d/media folders?

The example i have (with checking it all out first is):
svn checkout '' --depth immediates
svn update --set-depth exclude /b/media
svn update --set-depth exclude /d/media
svn update --set-depth infinity *

You can do an empty checkout, use update and switch to make the
directories into files, update the working copy to infinity, switch the
directories back to empty and then update to excluded:

svn co URL --depth empty wc
svn up --depth empty wc/b
svn up --depth empty wc/d
svn sw ^/some/file --ignore-ancestry wc/b/media
svn sw ^/some/file --ignore-ancestry wc/d/media
svn up --set-depth infinity wc
svn sw ^/b/media --set-depth empty --ignore-ancestry wc/b/media
svn sw ^/d/media --set-depth empty --ignore-ancestry wc/d/media
svn up --set-depth exclude wc/b/media
svn up --set-depth exclude wc/d/media



So by using switch you make it look like a file so it won't try to 
update its contents, then you switch it back to a directory and exclude 
/ depth empty it.


Would that switch call need the --relocate flag?

That solves half of the problem, I realize my example tree probably 
wasn't extensive enough. The /b/media and /d/media subfolders are like 3 
and 4 folders down in the tree, so its more like /b/1/2/3/media,  It 
would be ideal to not have to check out --depth empty all the parents 
directories. I suppose I should just checkout out those exact 
directories in tmp and then move them into the appropriate location?


Sorry for not getting that clear,

Lathan Bidwell

Re: check out everything except, '' subfolder should be shallower

[Lathan Bidwell]

On 01/24/2013 10:07 AM, Johan Corveleyn wrote:

On Thu, Jan 24, 2013 at 3:50 PM, Lathan Bidwell  wrote:

On 01/24/2013 05:14 AM, Philip Martin wrote:

Lathan Bidwell  writes:


How can i checkout out this sample repository without downloading the
/b/media/ and /d/media folders?

The example i have (with checking it all out first is):
svn checkout '' --depth immediates
svn update --set-depth exclude /b/media
svn update --set-depth exclude /d/media
svn update --set-depth infinity *

You can do an empty checkout, use update and switch to make the
directories into files, update the working copy to infinity, switch the
directories back to empty and then update to excluded:

svn co URL --depth empty wc
svn up --depth empty wc/b
svn up --depth empty wc/d
svn sw ^/some/file --ignore-ancestry wc/b/media
svn sw ^/some/file --ignore-ancestry wc/d/media
svn up --set-depth infinity wc
svn sw ^/b/media --set-depth empty --ignore-ancestry wc/b/media
svn sw ^/d/media --set-depth empty --ignore-ancestry wc/d/media
svn up --set-depth exclude wc/b/media
svn up --set-depth exclude wc/d/media


So by using switch you make it look like a file so it won't try to update
its contents, then you switch it back to a directory and exclude / depth
empty it.

Would that switch call need the --relocate flag?

That solves half of the problem, I realize my example tree probably wasn't
extensive enough. The /b/media and /d/media subfolders are like 3 and 4
folders down in the tree, so its more like /b/1/2/3/media,  It would be
ideal to not have to check out --depth empty all the parents directories.

As of 1.7, 'svn update' has a '--parents' option that helps with that
(see [1]). It creates any parent directory necessary, so you can do
this:

svn co URL --depth empty wc
svn up --parents --depth empty wc/1/2/3
...


I
suppose I should just checkout out those exact directories in tmp and then
move them into the appropriate location?

That won't work. Your checked out subdir will be a separate working
copy, which you then embed in your larger working copy. Those will be
embedded working copies, i.e. not the same as when the subdir is just
another part of a (sparse) working copy. With embedded working copies,
an 'svn up' of the parent working copy will not update the child
working copy (it will regard is as an unversioned part).


[1] http://subversion.tigris.org/issues/show_bug.cgi?id=3748
(Implement --parents option for svn update)




Okay, so thank you for showing me that use of switch and the new flag of 
--parents


Have a good day,

Lathan Bidwell

Re: FreeBSD project and subversion.

[Lathan Bidwell]

On 02/05/2013 01:14 PM, Stefan Sperling wrote:

On Tue, Feb 05, 2013 at 09:19:19AM -0800, Alexey Neyman wrote:

There is one more weird issue with svn diff, see the script below. The issue
is that "--old=A --new=B" is not opposite of "--old=B --new=A". I don't know
if it is a bug or another ambuguity I am not aware of :)

Here is the script:
[[[
#!/bin/bash

REPO=/tmp/foo
WC=/tmp/foo.wc

rm -rf $REPO $WC
svnadmin create $REPO
svn co -q file://$REPO $WC
cd $WC

echo r1 > a
svn add -q a
svn ci -q -m R1
echo r2 > a
svn ci -q -m R2
svn up -q -r 1
echo new > a
echo "Issue: --old=A --new=B is not opposite of --old=B --new=A"
echo "  Running: svn di --old=^/ --new=."
svn di --old=^/ --new=.
echo "  Running: svn di --old=. --new=^/"
svn di --old=. --new=^/
]]]

And here is the output (svn 1.7.6):
[[[
Issue: --old=A --new=B is not opposite of --old=B --new=A
   Running: svn di --old=^/ --new=.
Index: a
===
--- a   (.../file:///tmp/foo)   (revision 2)
+++ a   (working copy)
@@ -1 +1 @@
-r2
+new
   Running: svn di --old=. --new=^/
Index: a
===
--- a   (working copy)
+++ a   (.../file:///tmp/foo)   (revision 2)
@@ -1 +1 @@
-r1
+r2
]]]

Regards,
Alexey.

I can reproduce this with a trunk build. Can you please file an issue
for this? I'm not going to get to this right away. Thanks!



Here is the issue that I see:

The --old=. get's the workspace version of ., but --new get's the 
non-changed version of /.


So, I believe it is comparing "r1" with the r2 contents of "r2" and not 
comparing both workspace versions.


RevContents
1r1
2r2
2*  new

2* only get's referenced when it is in the --old position,
2 get's used when its in the --new position.


Please correct me if I'm wrong about this, but that is what seems to be 
a logical reasoning behind that behavior.


Lathan

Re: Discrepancies in svn mirror created with svnsync

[Lathan Bidwell]

  
  
Zach, the email to unsubscribe is:
  
  users-unsubscr...@subversion.apache.org
  
  
  On 02/08/2013 09:47 AM, Zachary Burnham wrote:


  
  unsubscribe
  

Z

  
  

Zachary Burnham | Web
  Developer
  Energy
  Federation Inc | 1 Willow Street |
  Southborough, MA 01772
  508.870.2277
  x4467 | f 888.440.4219 
zburn...@efi.org | efi.org

  
  
  

  
  
  
  
On Feb 8, 2013, at 9:45 AM, Stefan Sperling 
  wrote:

On Fri, Feb 08, 2013 at 03:45:16PM
  +0200, Marius Gedminas wrote:
  On Fri, Feb 08, 2013 at 11:44:40AM
+0100, Andreas Krey wrote:
On Thu, 07 Feb 2013 23:00:33 +,
  Marius Gedminas wrote:
  ...
  The cron script runs svnsync every
5 minutes. 
  
  
  Do you make sure svnsync isn't started anew when the
  previous instance
  hasn't terminated yet? (I don't know if that matters.)


No.  Here's my /etc/cron.d/zope-svn-mirror:

 # Mirror the Zope repository
 */5 * * * * root /usr/local/sbin/update-zope-mirror >
/dev/null

and here's my /usr/local/sbin/update-zope-mirror:

 #!/bin/sh
 /usr/bin/sudo -u syncuser /usr/bin/svnsync sync file:///stuff/zope-mirror

It's possible that a temporal overlap happened.

Marius Gedminas
  
  
  I cannot tell you what happened here and why the revisions in
  the
  mirro are empty. That sure is concerning.
  
  However there are known race conditions in svnsync in
  Subversion 1.6.
  See http://subversion.apache.org/docs/release-notes/1.7.html#atomic-revprops
  
  So you should definitely wrap svnsync in a tool like lockfile
  (part of
  procmail), or upgrade to 1.7.
  
  It would be interesting to know if this problem also appears
  with
  svnsync from 1.7. Note that with file:// URLs the svnsync you
  are running
  is both client and server from the mirror repository's point
  of view.
  So the version running on svn.zope.org doesn't really
  matter (though I
  checked, and it appears to be severely outdated...)

  
  
  
  
  
  
  Spam
  Not
spam
  Forget
previous vote

  


  

Merge trunk and prod directories without workspace

[Lathan Bidwell]

Hi,

I have a content management system running on top of SVN. My web servers
run a post commit hook that does svn update off of svnlook after every
commit.

I currently have a "Publish" operation which I implement by doing svn
delete $prod_url && svn cp $trunk_url $prod_url. (both repo urls)

This causes problems because the post commit hook triggers a delete of the
folder on my production web server, and then sometimes takes longer to
re-download all the content (some folders have some decent media, about
15-30 gig).

General Question: How can I do this operation without checking out the
folder to a workspace, and do it in 1 revision?

Are there reasons why there isn't a repo to repo merge action? or could
that be looked into in future versions?

Thanks for your help,
Lathan

Re: Merge trunk and prod directories without workspace

[Lathan Bidwell]

On Mon, Mar 16, 2015 at 3:15 PM, Ryan Schmidt <
subversion-2...@ryandesign.com> wrote:

>
> On Mar 16, 2015, at 8:19 AM, Lathan Bidwell wrote:
>
> > I have a content management system running on top of SVN. My web servers
> run a post commit hook that does svn update off of svnlook after every
> commit.
> >
> > I currently have a "Publish" operation which I implement by doing svn
> delete $prod_url && svn cp $trunk_url $prod_url. (both repo urls)
> >
> > This causes problems because the post commit hook triggers a delete of
> the folder on my production web server, and then sometimes takes longer to
> re-download all the content (some folders have some decent media, about
> 15-30 gig).
> >
> > General Question: How can I do this operation without checking out the
> folder to a workspace, and do it in 1 revision?
>
> svnmucc can do it in one revision.


That looks interesting, I haven't seen that before. I will look into that,
hopefully I can find a non-command line equivalent.


>

Or you could use the language bindings.
>

I am using perl SWIG bindings, I believe they are somewhat similar to ...
java's?

But the docs seem to be very action based, and I don't see anything related
to holding a transaction. According to my knowledge there aren't actions
that don't end in a commit if it is working on a repository url.

If I am wrong, please show me these actions / parameters for these
behaviors.


>
> > Are there reasons why there isn't a repo to repo merge action? or could
> that be looked into in future versions?
>
> I'm not sure I understand. What would this action do?
>
Current merge behavior says merge changes from a repository url to my
workspace. So I could checkout out a production branch, and merge in the
committed test branch.

What I'd like is to say: "My production branch is at this repository url,
merge this test repository url into that" there would have to be difference
in the mine / theirs conflict settings. And don't require a workspace to
work in.

Re: Merge trunk and prod directories without workspace

[Lathan Bidwell]

On Mon, Mar 16, 2015 at 4:44 PM, Les Mikesell  wrote:

> On Mon, Mar 16, 2015 at 3:16 PM, Lathan Bidwell 
> wrote:
> >
> >>
> >> > I have a content management system running on top of SVN. My web
> servers
> >> > run a post commit hook that does svn update off of svnlook after every
> >> > commit.
> >> >
> >> > I currently have a "Publish" operation which I implement by doing svn
> >> > delete $prod_url && svn cp $trunk_url $prod_url. (both repo urls)
> >> >
> >> > This causes problems because the post commit hook triggers a delete of
> >> > the folder on my production web server, and then sometimes takes
> longer to
> >> > re-download all the content (some folders have some decent media,
> about
> >> > 15-30 gig).
>
> Don't you really want to just 'svn switch' your production workspace
> to the new production target url instead of deleting and checking out
> again?  As long as the content shares ancestry it should just move the
> differences.
>
> --
>Les Mikesell
>  lesmikes...@gmail.com
>
> The copy and delete is not ideal. What I am really trying to do is deploy
the version of the trunk branch to the production branch.

I am not changing my production target url. I am trying to send new changes
from trunk to prod, while keeping trunk as a separate branch.

Before and after a "publish" action, there will still be those 2 branches:
/trunk/blah
/prod/blah

They just happen to have the same content until someone makes new changes
to /trunk/blah/.

Publish should make the /prod/ be the same as the /trunk/ while keeping
them separate enough to make changes to /trunk/ and not touch /prod/ (until
the next publish).

I need to be able to stage changes and preview them (preview server runs
off the /trunk/ branch).

Lathan

Re: Merge trunk and prod directories without workspace

[Lathan Bidwell]

On Mon, Mar 16, 2015 at 5:15 PM,  wrote:

>
> On Mar 16, 2015, at 2:04 PM, Lathan Bidwell  wrote:
>
>
>
> On Mon, Mar 16, 2015 at 4:44 PM, Les Mikesell 
> wrote:
>
>> On Mon, Mar 16, 2015 at 3:16 PM, Lathan Bidwell 
>> wrote:
>> >
>> >>
>> >> > I have a content management system running on top of SVN. My web
>> servers
>> >> > run a post commit hook that does svn update off of svnlook after
>> every
>> >> > commit.
>> >> >
>> >> > I currently have a "Publish" operation which I implement by doing svn
>> >> > delete $prod_url && svn cp $trunk_url $prod_url. (both repo urls)
>> >> >
>> >> > This causes problems because the post commit hook triggers a delete
>> of
>> >> > the folder on my production web server, and then sometimes takes
>> longer to
>> >> > re-download all the content (some folders have some decent media,
>> about
>> >> > 15-30 gig).
>>
>> Don't you really want to just 'svn switch' your production workspace
>> to the new production target url instead of deleting and checking out
>> again?  As long as the content shares ancestry it should just move the
>> differences.
>>
>> --
>>Les Mikesell
>>  lesmikes...@gmail.com
>>
>> The copy and delete is not ideal. What I am really trying to do is deploy
> the version of the trunk branch to the production branch.
>
> I am not changing my production target url. I am trying to send new
> changes from trunk to prod, while keeping trunk as a separate branch.
>
> Before and after a "publish" action, there will still be those 2 branches:
> /trunk/blah
> /prod/blah
>
> They just happen to have the same content until someone makes new changes
> to /trunk/blah/.
>
> Publish should make the /prod/ be the same as the /trunk/ while keeping
> them separate enough to make changes to /trunk/ and not touch /prod/ (until
> the next publish).
>
> I need to be able to stage changes and preview them (preview server runs
> off the /trunk/ branch).
>
> Lathan
>
>
> In Git, this would involve simply moving a branch pointer to the new
> commit. With SVN, you only have two options: 1) merge the changes that
> occurred in trunk into prod, which probably could get messsy, or 2) delete
> prod and copy trunk to a new prod.
>
> The delete/copy is the only option you have if trunk and prod have no
> common ancestry.
>
> Another alternative would be to use "export" from trunk and store your
> production code snapshot into a tarball that is "released" and archived
> outside of SVN entirely. (e.g. burn to DVD).
>

The prod branch is only updated by copying from trunk, so they do share
ancestry.

I have concerns about 2 things:
1) I don't have the disk / time to download/ ...  to checkout the folder I
am publishing
2) If files are deleted in trunk, then trunk is merged into prod, I need to
be 100% sure that a theirs-conflict will ensure that prod is the same as
trunk, not that prod has some of the old version still left, files that
were deleted in trunk, 

Re: Merge trunk and prod directories without workspace

[Lathan Bidwell]

On Mon, Mar 16, 2015 at 5:24 PM, Les Mikesell  wrote:

> On Mon, Mar 16, 2015 at 4:04 PM, Lathan Bidwell 
> wrote:
> >
> >>
> >> Don't you really want to just 'svn switch' your production workspace
> >> to the new production target url instead of deleting and checking out
> >> again?  As long as the content shares ancestry it should just move the
> >> differences.
> >>
>
> > The copy and delete is not ideal. What I am really trying to do is deploy
> > the version of the trunk branch to the production branch.
>
> I don't see why delete/copy in the repository is a problem.  But why
> track the delete with a post-commit hook?
>
> > I am not changing my production target url. I am trying to send new
> changes
> > from trunk to prod, while keeping trunk as a separate branch.
> >
> > Before and after a "publish" action, there will still be those 2
> branches:
> > /trunk/blah
> > /prod/blah
>
> I usually think in revision numbers or tag names instead of pretending
> there was only one. If, instead of tracking HEAD, you copied each
> release to a new TAG with your own naming scheme you could just switch
> your production workspace to that TAG instead of arranging for what
> you want to be at the head of a branch.  And as a side effect you get
> an easily tracked name for the tag you would need to revert those
> changes.
>
>
Hard to make friendly names automatically.

What I failed to mention before is that these publishes happen closer to
the leaf nodes, more like: blah/foo/bar and blah/foo/hi both get published,
but blah/foo/bye didn't get published.

Each user in the content Management System has folders that they have
access to, and they can publish any files or folders in "their area".


The problem with using switch is its hard to know where your production
branch is, and quite easy to accidentally svn update -r HEAD and
accidentally deploy things.

I'd also like to know in SVN if there are unpublished changes to a file or
folder (separate topic) which just using switch on the workspace would make
it more complicated.

> They just happen to have the same content until someone makes new changes
> to
> > /trunk/blah/.
> >
> > Publish should make the /prod/ be the same as the /trunk/ while keeping
> them
> > separate enough to make changes to /trunk/ and not touch /prod/ (until
> the
> > next publish).
>
> > I need to be able to stage changes and preview them (preview server runs
> off
> > the /trunk/ branch).
>
> Alternatively, you could merge the trunk changes into your preview
> workspace and commit that to production, with the edits actually being
> done elsewhere.
>
> I will talk with my colleague about that idea, although I think the last
time I mentioned it there was some reason why it was problematic.

--
>Les Mikesell
>  lesmikes...@gmail.com.

Re: Merge trunk and prod directories without workspace

[Lathan Bidwell]

On Mon, Mar 16, 2015 at 5:49 PM, Les Mikesell  wrote:

> On Mon, Mar 16, 2015 at 4:33 PM, Lathan Bidwell 
> wrote:
> >
> >>
> >> I usually think in revision numbers or tag names instead of pretending
> >> there was only one. If, instead of tracking HEAD, you copied each
> >> release to a new TAG with your own naming scheme you could just switch
> >> your production workspace to that TAG instead of arranging for what
> >> you want to be at the head of a branch.  And as a side effect you get
> >> an easily tracked name for the tag you would need to revert those
> >> changes.
> >>
> >
> > Hard to make friendly names automatically.
>
> Also, these publishes are not like putting out a full release of a
software package. The entire branch is a website for a university. We never
publish everything at the same time. So, I'm not sure how I could implement
a useful TAG every time someone decided to publish a subfolder or
index.html file.


> They usually end up being release numbers with a base name and
> major/minor components, but much more related to the release/publish
> step than intermediate commits.
>
> > What I failed to mention before is that these publishes happen closer to
> the
> > leaf nodes, more like: blah/foo/bar and blah/foo/hi both get published,
> but
> > blah/foo/bye didn't get published.
> >
> > Each user in the content Management System has folders that they have
> access
> > to, and they can publish any files or folders in "their area".
>
> So, how would you track those if you wanted to revert?
>

By revision number pulled from svn log

>
> > The problem with using switch is its hard to know where your production
> > branch is, and quite easy to accidentally svn update -r HEAD and
> > accidentally deploy things.
>
> It's a matter of workflow.  I don't see why it isn't just as easy to
> deploy by incorrectly publishing something to your branch head.
>

The difference is, if you publish something to the branch head, there is a
revision that you see in a log, and could revert.

if my prod checkout has a bunch of folders each switched to a different
revision, if I lose that filesystem and have to recheck out that workspace
I've lost all information about what is published.

if I copy my entire 250 gig branch, is SVN going to deduplicate that
internally and not need more disk?



Most of my publishes happen on subfolders of the full tree, so basically
every folder / file could have a different publsh status: incoming add,
incoming update, incoming delete. with different revisions.

file trunk rev prod rev
/a/b/c50004850incoming update
/1/2/32000   2001 up to date
/x/y/z90007438incoming update
/x/y/z/index.html   8000 8001up to date

>
> > I'd also like to know in SVN if there are unpublished changes to a file
> or
> > folder (separate topic) which just using switch on the workspace would
> make
> > it more complicated.
>
> Do you mean diffs against trunk/HEAD?  That should be the same
> regardless of the workspace url.
>
> What I currently do is compare the rev number from the prod branch and the
trunk branch for an item, and if there are newer trunk revisions, then I
show the user that this file has incoming updates.


> >> > I need to be able to stage changes and preview them (preview server
> runs
> >> > off
> >> > the /trunk/ branch).
> >>
> >> Alternatively, you could merge the trunk changes into your preview
> >> workspace and commit that to production, with the edits actually being
> >> done elsewhere.
> >>
> > I will talk with my colleague about that idea, although I think the last
> > time I mentioned it there was some reason why it was problematic.
>
> I would think you would really want to preview the exact copy of what
> is about to be pushed to production instead of hoping a a merge ends
> up with the changes you wanted.   And along those lines it is possible
> to have things in your staging/preview workspace that aren't even
> committed if you aren't careful about it.  Copy to tag/preview
> tag/switch production to tag/ is a safer approach to be sure no
> uncommitted changes happen in between.
>

You are correct in why I have not used merge for this operation before.

My preview runs off my trunk branch, so when they preview they see most up
to date (albeit unpublished) version.

>
> --
>Les Mikesell
> lesmikes...@gmail.com
>
>

Re: Merge trunk and prod directories without workspace

[Lathan Bidwell]

On Tue, Mar 17, 2015 at 10:58 PM, Les Mikesell 
wrote:

> On Tue, Mar 17, 2015 at 9:45 PM, Les Mikesell 
> wrote:
>
> Sorry - accidentally sent before finished...
>
> > On Tue, Mar 17, 2015 at 8:21 AM, Lathan Bidwell 
> wrote:
> >>
> >>>
> >> Also, these publishes are not like putting out a full release of a
> software
> >> package. The entire branch is a website for a university. We never
> publish
> >> everything at the same time. So, I'm not sure how I could implement a
> useful
> >> TAG every time someone decided to publish a subfolder or index.html
> file.
> >>
> >
> > If the sections are independent subdirectories, you might want to
> > manage them independently.
> >>>
> >
> >>> > The problem with using switch is its hard to know where your
> production
> >>> > branch is, and quite easy to accidentally svn update -r HEAD and
> >>> > accidentally deploy things.
> >>>
> >>> It's a matter of workflow.  I don't see why it isn't just as easy to
> >>> deploy by incorrectly publishing something to your branch head.
> >>
> >>
> >> The difference is, if you publish something to the branch head, there
> is a
> >> revision that you see in a log, and could revert.
> >>
> >> if my prod checkout has a bunch of folders each switched to a different
> >> revision, if I lose that filesystem and have to recheck out that
> workspace
> >> I've lost all information about what is published.
> >
> > Except for special cases where you've reverted that would normally be
> > your latest release tag. But, with a workflow of publishing by
> > tracking tags you would probably track the tag names with some
> > process, maybe logging who approved it and when.
> >
> >> if I copy my entire 250 gig branch, is SVN going to deduplicate that
> >> internally and not need more disk?
> >
> > Svn copies are very cheap. Probably much more so than a merge that
> > ends up not being an exact copy of an ancestor revision.
> >
> >> Most of my publishes happen on subfolders of the full tree, so basically
> >> every folder / file could have a different publsh status: incoming add,
> >> incoming update, incoming delete. with different revisions.
> >>
> >> file trunk rev prod rev
> >> /a/b/c50004850incoming update
> >> /1/2/32000   2001 up to date
> >> /x/y/z90007438incoming update
> >> /x/y/z/index.html   8000 8001up to date
>
> So only one outstanding change (set) is possible?
>

a Publish action  operates on 1 file or folder at once.

>
> >>> Do you mean diffs against trunk/HEAD?  That should be the same
> >>> regardless of the workspace url.
> >>>
> >> What I currently do is compare the rev number from the prod branch and
> the
> >> trunk branch for an item, and if there are newer trunk revisions, then I
> >> show the user that this file has incoming updates.
>
> That would not be much different if your published copy was a tag.
>
> >> My preview runs off my trunk branch, so when they preview they see most
> up
> >> to date (albeit unpublished) version.
>
> Where are the edits/commits happening?  If they are not made on the
> preview system, I don't think it would change much to do a merge from
> trunk into the previous production workspace there, and publish by
> committing to production.
>
most of the commits are using direct repository actions. There are a couple
actions that do a sparse checkout for an action.

>
> --
>   Les Mikesell
> lesmikes...@gmail.com
>

Re: Merge trunk and prod directories without workspace

[Lathan Bidwell]

On Sat, Mar 21, 2015 at 7:07 PM, Les Mikesell  wrote:

> On Fri, Mar 20, 2015 at 9:14 AM, Lathan Bidwell 
> wrote:
> >
> >> >> file trunk rev prod rev
> >> >> /a/b/c50004850incoming update
> >> >> /1/2/32000   2001 up to date
> >> >> /x/y/z90007438incoming update
> >> >> /x/y/z/index.html   8000 8001up to date
> >>
> >> So only one outstanding change (set) is possible?
> >
> >
> > a Publish action  operates on 1 file or folder at once.
>
> But what about concurrent but different change sets?.  That is, how do
> you handle someone who might be preparing a large set of changes that
> may take some time to complete and preview, but meanwhile needs to
> make some small updates to the existing content?   I'd expect
> something this complex to need multiple branches for development with
> the changes being merged to the preview workspace.   Or maybe even a
> tree of external linkages with the ability to either track the HEAD of
> the external parts or to be pegged to revisions as determined by the
> preview results.
>
>
Our web team has run into that a couple of times, where we are doing a site
upgrade, but it has not been a big issue.

Most of the time, making changes to the low level templates doesn't
interfere with users editing the page content.


> >>
> >> Where are the edits/commits happening?  If they are not made on the
> >> preview system, I don't think it would change much to do a merge from
> >> trunk into the previous production workspace there, and publish by
> >> committing to production.
> >
> > most of the commits are using direct repository actions. There are a
> couple
> > actions that do a sparse checkout for an action.
>
> New imports or copies from branches you haven't mentioned?  Imports
> won't have any other ancestry.
>
> --
>   Les Mikesell
> lesmikes...@gmail.com
>

Perl Bindings: Assertion svn_uri_is_canonical failed

[Lathan Bidwell]

I am running SVN 1.6 (will be upgrading to 1.8.8) through apache 2.4 /
mod_perl.

I'm trying to get email notifications of errors, but whenever libsvn fails
one of its assertions, it dies, and causes the whole apache process to core
dump / seg fault.

Is there some way to either check for these assertions in a non-lethal way
before hand, or make it possible to surivve the error so my error reporting
can run?

Usually these assertions are problems with my url handling: double slash,
or slash at end of directory. But I'd still like those errors to be
reported, so I know that my users are hitting problems.

Thanks,
Lathan

Re: Perl Bindings: Assertion svn_uri_is_canonical failed

[Lathan Bidwell]

I fully agree, the error is correct and deserved.
It is happening on both my 1.6 prod servers and my 1.8.8 test servers.

And I fully understand, and will do more to sanitize my inputs.

But the fact that warnings cause a seg fault / core fault of the whole
apache process makes my error reporting very difficult.

All I am asking is how / why does that error completely kill my execution
chain.

Perl test case example below:

#!/usr/bin/perl
use strict;
use warnings;
use Data::Dumper;
use SVN::Client;
sub SVN_CMS_BASE { return 'http://websvn.cc.domain.com/svn/www/cms' }

sub get_svn_ctx
{
return new SVN::Client(
auth => [
SVN::Client::get_ssl_server_trust_prompt_provider(\&_trust_callback),

# SVN::Client::get_ssl_server_trust_file_provider(),
SVN::Client::get_simple_provider(),
SVN::Client::get_simple_prompt_provider(\&simple_prompt, 2),
SVN::Client::get_username_provider()
]
) || warn "Unable to get connection...?!?";
}

sub simple_prompt
{
my $cred = shift;
my $realm= shift;
my $default_username = shift;
my $may_save = shift;
my $pool = shift;

$cred->username('svnuser');
$cred->password('svnpassword');
}

my $ctx = get_svn_ctx();

eval{
$ctx->ls(SVN_CMS_BASE . '/','HEAD',1);
};
if($@){
print "Error Occured!!! Let's report it\n";
die $@;
}
print "We survived!!\n";

On Tue, Jan 27, 2015 at 11:05 AM, Stefan Sperling  wrote:

> On Tue, Jan 27, 2015 at 10:38:31AM -0500, Lathan Bidwell wrote:
> > I am running SVN 1.6 (will be upgrading to 1.8.8) through apache 2.4 /
> > mod_perl.
> >
> > I'm trying to get email notifications of errors, but whenever libsvn
> fails
> > one of its assertions, it dies, and causes the whole apache process to
> core
> > dump / seg fault.
> >
> > Is there some way to either check for these assertions in a non-lethal
> way
> > before hand, or make it possible to surivve the error so my error
> reporting
> > can run?
> >
> > Usually these assertions are problems with my url handling: double slash,
> > or slash at end of directory. But I'd still like those errors to be
> > reported, so I know that my users are hitting problems.
> >
> > Thanks,
> > Lathan
>
> A failure in svn_uri_is_canonical() sounds like you are running
> something (a Perl script since you mention mod_perl?) against the
> SVN APIs that provides bad input to SVN.  Is this the case? If so,
> whatever is running will need to be fixed to provide valid input.
> To find out what SVN considers canonical please refer to the comment
> on top of this file:
>
> https://svn.apache.org/repos/asf/subversion/trunk/subversion/include/svn_dirent_uri.h
> as well as the comment on top of the function svn_uri_canonicalize()
> in the same file.
>
> 1.6 is very old so it's possible that your problems will disappear after
> an update to 1.8. If that's not the case then please invest some time
> into writing a problem report that includes detailed information about
> your setup (actual error messages extracted from log files, config files,
> hook scripts you are running, etc.)
>
>
> --
> BEGIN-ANTISPAM-VOTING-LINKS
> --
>
> NOTE: This message was trained as non-spam.  If this is wrong,
> please correct the training as soon as possible.
>
> Teach CanIt if this mail (ID 0aNJ45U2o) is spam:
> Spam:
> http://www.andrews.edu/spam/b.php?i=0aNJ45U2o&m=2a430390b425&c=s
> Not spam:
> http://www.andrews.edu/spam/b.php?i=0aNJ45U2o&m=2a430390b425&c=n
> Forget vote:
> http://www.andrews.edu/spam/b.php?i=0aNJ45U2o&m=2a430390b425&c=f
> --
> END-ANTISPAM-VOTING-LINKS
>
>

Re: Perl Bindings: Assertion svn_uri_is_canonical failed

[Lathan Bidwell]

> svn_uri_canonicalize(). Else you'll get undefined behaviour,
>
> I think I have found the SWIG perl binding for one of these cleansing
functions, I will test that out and put it in.

By the way, the SWIG definitions are different enough that they could use
their own documentation page. svn_uri_canonicalize isn't passed, but I
think it might be  url_from_path

However, even fixing that, I am still worried about errors that just crash
the apache process.

Branko Čibej says:
>I think he's asking whether he can intercept the assertions before they
abort the process.

Yes, I'd like to intercept the errors, notify the development email address
of the error, and give my user a nicer error message.

I'm not that great going through SWIG source, what would it look like?

Lathan

Re: Perl Bindings: Assertion svn_uri_is_canonical failed

[Lathan Bidwell]

In the Perl SWIG bindings:

$ctx->url_from_path

I believe calls the svn_uri_canonicalize in 1.8.8, but I believe that its a
secondary effect (in 1.6, it doesn't cleanse the url)

Is there a perl SWIG binding for svn_uri_canonicalize?

Lathan

On Tue, Jan 27, 2015 at 12:07 PM, Lathan Bidwell  wrote:

>
> svn_uri_canonicalize(). Else you'll get undefined behaviour,
>>
>> I think I have found the SWIG perl binding for one of these cleansing
> functions, I will test that out and put it in.
>
> By the way, the SWIG definitions are different enough that they could use
> their own documentation page. svn_uri_canonicalize isn't passed, but I
> think it might be  url_from_path
>
> However, even fixing that, I am still worried about errors that just crash
> the apache process.
>
> Branko Čibej says:
> >I think he's asking whether he can intercept the assertions before they
> abort the process.
>
> Yes, I'd like to intercept the errors, notify the development email
> address of the error, and give my user a nicer error message.
>
> I'm not that great going through SWIG source, what would it look like?
>
> Lathan
>

Re: Perl Bindings: Assertion svn_uri_is_canonical failed

[Lathan Bidwell]

Hi Ben,

Thanks, you've answered all my questions before I could even ask them.

I wrote a perl function to find those calls, and pull usage out of the
runtime errors.

But now, perldoc ftw.

By the way, these aren't too bad for docs:
http://search.cpan.org/~mschwern/Alien-SVN-v1.8.11.0/

On Tue, Jan 27, 2015 at 4:12 PM, Ben Reser  wrote:

> On 1/27/15 9:07 AM, Lathan Bidwell wrote:
> > By the way, the SWIG definitions are different enough that they could
> use their
> > own documentation page.
>
> They actually do have a fair amount of documentation.  It's just not on a
> web
> page on the website.
>
> Use the perldoc command against the modules e.g.
> perldoc SVN::Client
> perldoc SVN::Core
> and so on...
>
> > However, even fixing that, I am still worried about errors that just
> crash the
> > apache process.
>
> All the SWIG bindings require the user to do their own path
> canonicalizations.
>  You probably want to read this bit of documentation from the C API:
> http://subversion.apache.org/docs/api/1.8/svn__dirent__uri_8h.html#details
>
> As mentioned by Stefan Sperling failure to canonicalize paths will result
> in
> undefined behavior, generally aborts().  This is a design decision of the C
> APIs.  Unfortunately, nobody decided to make the SWIG bindings
> automatically
> canonicalize for you like JavaHL does.
>
> I believe our APIs always provide canonical paths.  So any place you're
> generating your own paths (and yes URIs are paths) you need to do your own
> canonicalization before passing it to the SVN libraries.
>
> I updated the documentation to reflect this last year on trunk, and it'll
> show
> up in the 1.9.0 release.
>
> For instance the following definitions of $path and $target help point you
> the
> right way:
>$path
>This is a path to a file or directory on the local file system.
>Paths need to be canonicalized before being passed into the
>Subversion APIs.  Paths on the local file system are called
> dirents
>and can be canonicalized by calling
>"SVN::Core::dirent_canonicalize".
>
>$target
>This is a path to a file or directory in a working copy or a
> URL to
>a file or directory in a subversion repository.  Both paths and
>URLs need to be canonicalized before being passed into the
>Subversion APIs.  Paths on the local file system are called
> dirents
>and can be canonicalized by calling
>"SVN::Core::dirent_canonicalize".  URLs can be canonicalized by
>calling "SVN::Core::uri_canonicalize".
>
> The example in the SVN::Client has also been updated to show that you
> should be
> doing this:
>
>use SVN::Client;
>my $client = new SVN::Client();
>
># setup to handle authentication the same as the command line
> client
>my $config_dir = undef; # use default location
>my $config = SVN:Core::config_get_config($config_dir);
>my $config_category = $cfg->{SVN::Core::CONFIG_CATEGORY_CONFIG};
>$client->auth(
>  SVN::Core::cmdline_create_auth_baton(0,
>  #non_interactive
>   undef,   #username
>   undef,   #password
>   $config_dir,
>   0,
>  #no_auth_cache
>   0,
> #trust_server_cert
>   $config_category,
>   undef)
>  #cancel_callback
>);
>
># Use first argument as target and canonicalize it before using
>my $target;
>if (SVN::Core::path_is_url($ARGV[0])) {
>  $target = SVN::Core::uri_canonicalize($ARGV[0]);
>} else {
>  $target = SVN::Core::dirent_canonicalize($ARGV[0]);
>}
>
># fetch the head revision of the target
>$client->cat(\*STDOUT, $target, 'HEAD');
>
> > Yes, I'd like to intercept the errors, notify the development email
> address of
> > the error, and give my user a nicer error message.
> >
> > I'm not that great going through SWIG source, what would it look like?
>
> You'd need to use svn_error_set_malfunction_handler():
>
> http://subversion.apache.org/docs/api/1.8/group__svn__error__malfunction__assertion.html#ga399ab33aa7fcea5cc776a62b56