Re: Merging copy operations

[Andreas Krey]

On Wed, 10 Aug 2011 23:54:24 +, Johan Corveleyn wrote:
...
> I think what you're describing is issue #2685:
> 
> http://subversion.tigris.org/issues/show_bug.cgi?id=2685 (Move + Merge
> => lose modifications)
...
> Also, I'm not sure if mergeinfo will be a problem. Maybe you should
> just try it with a test repository.

The script in https://gist.github.com/1139064 demonstrates the problem
of issue #2685, which is five years old; before mergeinfo even existed.

It may well be that you lose some mergeinfo as well in the process.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Adding license text to files

[Thorsten Schöning]

Guten Tag Jason Aubrey,
am Mittwoch, 10. August 2011 um 18:06 schrieben Sie:

> I'd like to use keyword substitution or something like it to
> automatically append/update license information in a large collection
> of files. In other words, I'd like the licensing information to be a
> property of the file, but also appear as text in the file.  I can do
> the former with properties, but can't see how to do the latter in some
> automatic easy way. (Also, ideally, the license text in the file would
> come from the property on the file. )

As already said, this is not possible without doing on your own, but
besides that, what's the benefit of having the license text as a
property on each file, which gets substituted into the file, over
having the text directly versioned in the file? If I understand you
right, you would have to change the property of each file for changing
the license text which doesn't seem easier that replacing the text
directly in the file with some text replacement tool. In my opinion
the property approach is even less handy because you don't have things
like blame and diffs where you can see who changed what line of the
license and why.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
 
Telefon: Potsdam: 0331-743881-0
E-Mail:  tschoen...@am-soft.de
Web: http://www.am-soft.de

AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow

RE: Help Needed regarding svn master-slave configuration

[Sharma, Gaurav]

Hi Nico, Uli and All,

Thanks for your replies.
You got me right that I am willing to implement a write-through-proxy set up 
where every WRITE request is redirected to master (server) by slave (server) 
while every READ request is served locally by the slave. I understand the risk 
of multiple users committing at the same time and currently I am not worried 
about it as the purpose of this setup is limited to very few users and I will 
look to have a work around of this problem later on, once this setup gets going.

So I changed my setup to work with HTTP rather on HTTP as I am having issue in 
accepting ssl-certificate from master. For the time being I will work with HTTP 
once it starts working I will move it to HTTPS. I am again describing the steps 
and configuration so that no confusion remains.

ON MASTER (server)

/etc/apache2/mods-available/dav_svn.conf


  DAV svn
  SVNParentPath /home/svn
  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /etc/apache2/dav_svn.passwd
  Require valid-user  

 

post-commit

/usr/bin/svnsync sync --username mirrorsync --password 123 --non-interactive 
http://slave-ip/svn-proxy-sync/mirror-repo

post-revprop-change

/usr/bin/svnsync copy-revprops --username mirrorsync --password 123 
http://slave-ip/svn-proxy-sync/mirror-repo $REV

ON SLAVE (server)

/etc/apache2/mods-available/dav_svn.conf 


  DAV svn
  SVNParentPath /home/svn
  SVNMasterURI http://master-ip/svn
  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /etc/apache2/dav_svn.passwd
  Require valid-user



  DAV svn
  SVNParentPath /home/svn
  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /etc/apache2/dav_svn.passwd  
  Require valid-user
 

start-commit 

if [ "$USER" = "mirrorsync" ];
  then exit 0;
fi
echo "Only the mirrorsync user may commit new revisions" >&2 exit 1

pre-revprop-change

if [ "$USER" = "mirrorsync" ];
  then exit 0;
fi
echo "Only the mirrorsync user may change revision properties" >&2 exit 1

"mirrorsync" is the user that exists in the /etc/apache2/dav_svn.passwd file.

In the above set up if as soon as something is COMMITED to master (directly) 
without involving slave it gets synchronized with the slave as well. 
If I try to checkout from the slave it also works fine.

BUT if I try to commit to the slave I get error 

"svn: Commit failed (details follow):"
"svn: Could not open the requested SVN filesystem"

This error is present inside the error.log file of the master so I assume the 
COMMIT request was redirected to master but it couldn't open the svn repository 
on the master. 
The group and the user to which svn repository belong is "www-data" on both 
master and slave with rwx permissions.

Svn repository resides at /home/svn/master-repo on MASTER and at 
/home/svn/mirror-repo on SLAVE

I hope this information will help you to find some solution to my problem.

Thanks
Gaurav


-Original Message-
From: Nico Kadel-Garcia [mailto:nka...@gmail.com] 
Sent: Thursday, August 11, 2011 12:35 AM
To: users@subversion.apache.org
Subject: Re: Help Needed regarding svn master-slave configuration

On Wed, Aug 10, 2011 at 8:04 AM, Ulrich Eckhardt
 wrote:
> On Wednesday 10 August 2011, Nico Kadel-Garcia wrote:
>> On Wed, Aug 10, 2011 at 3:40 AM, Ulrich Eckhardt
>>  wrote:
> [..]
>> > 3. connect the repositories
>> > This involves creating a post-commit hook that svnsyncs the changes to
>> > the secondary repository and one for the rev-prop changes, but you seem
>> > to have these set up already.
>> > 4. create a transparent write-proxy
>> > This requires Apache (the rest could be dove with svnserve, too) and
>> > should also be documented. I never made this step though but only the
>> > former three, since the write-proxy wasn't my requirement.
>>
>> Step 3 and 4 *are not enough*. The synchronization would have to occur
>> at the "commit" stage, not the "post-commit", because "commit" has to
>> be atomic with Subversion. Post-commit is nominally allowed to fail
>> without stopping the commit operation. And the only support I've seen
>> for that sort of thing is in Wandisco's "Multi-Site" tool.
>
> I don't think I understand you. Or maybe you don't understand me
>
> Step three above means that new revisions in the primary repository are synced
> to the secondary repository. I didn't explicitly say that this is a one-way
> operation, but that's what I meant. In no case can you directly commit to the
> secondary repository.

The implication, from the original poster's question and, I thought,
from your response, was that you could do this on the *slave* server,
accept commits there, and push the changes to the master. This is what
I'm raising red flags: resolving potential "split-bran" operations due
to a master server being offline has to be done at the commit stage,
not the post-commit stage.

Since this is not what you meant, I am re-assured.

> Step four is a setup of Apache that simply redirects any write request to the
> primary rep

Re: Adding license text to files

[Ulrich Eckhardt]

On Wednesday 10 August 2011, Jason Aubrey wrote:
> I'd like to use keyword substitution or something like it to
> automatically append/update license information in a large collection
> of files. In other words, I'd like the licensing information to be a
> property of the file, but also appear as text in the file.  I can do
> the former with properties, but can't see how to do the latter in some
> automatic easy way. (Also, ideally, the license text in the file would
> come from the property on the file. )

You discovered yourself that you can set arbitrary properties on a file and 
others already mentioned that you can't use this to expand keywords. What you 
can do though is to create a script that checks the license property and 
substitutes a placeholder in the file or prepends a header. What this doesn't 
achieve is that anybody checking out will see the license. That said, even SVN 
keyword substitution is performed on client-side, so it can be circumvented. 

There is another thing that comes to mind. You could include a text stanza 
like "see 'license.text' for licensing details" to the file and then use 
svn:external to reference the file from somewhere else. That would allow 
changing the license without having to touch hundreds of files.

Cheers!

Uli

-- 
ML: http://subversion.apache.org/docs/community-guide/mailing-lists.html
FAQ: http://subversion.apache.org/faq.html
Docs: http://svnbook.red-bean.com/

**
Domino Laser GmbH, Fangdieckstra�e 75a, 22547 Hamburg, Deutschland
Gesch�ftsf�hrer: Thorsten F�cking, Amtsgericht Hamburg HR B62 932
**
Visit our website at http://www.dominolaser.com
**
Diese E-Mail einschlie�lich s�mtlicher Anh�nge ist nur f�r den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empf�nger sein 
sollten. Die E-Mail ist in diesem Fall zu l�schen und darf weder gelesen, 
weitergeleitet, ver�ffentlicht oder anderweitig benutzt werden.
E-Mails k�nnen durch Dritte gelesen werden und Viren sowie nichtautorisierte 
�nderungen enthalten. Domino Laser GmbH ist f�r diese Folgen nicht 
verantwortlich.
**

Re: Merging copy operations

[Stefan Sperling]

On Thu, Aug 04, 2011 at 12:24:38PM +0200, Ulrich Eckhardt wrote:
> Hi!
> 
> I'm refactoring code and in that context I moved parts of one file to a 
> separate file, so I copied trunk/A to trunk/B and then hacked the two so that 
> each contained one part of the code. Then, when the whole works again, I 
> commit the whole in a commit. First question here: I consider that a normal 
> approach that should be supported, any objections here?

No objections to this approach.

> Then, lateron, I want to merge the changes. I then merge the revision from 
> trunk to the stable branch. What I noticed there is that in the branch, the 
> "copy from" property of the newly-created file "stable/B" points to 
> "trunk/A", 
> while I would have expected it to point to "stable/A" instead!

During a merge, Subversion does not replay copy operations within the
target branch. Doing so would be a lot more complicated than what it
is currently doing. If copyfrom points back to the merge source the
copyfrom path@rev will always exist. If copies are instead replayed within
the merge target and the copy source does not exist within the merge target
the copy cannot be replayed and tree conflict handling needs to kick in.

The behaviour you describe was implemented at long time before tree
conflicts even became a topic on the development roadmap.
So I would say this behaviour is simply the result of organic growth.

> Second question 
> here: In what case does the existing behaviour make sense? I'd say that when 
> merging, such copy-from paths must also be translated to the new tree. 

I agree. But it hasn't been implemented yet. I think it should
eventually be tackled, possibly when we get to the point where we
can try to improve tree-conflict handling for moves.

> However, if the path was outside the "from" tree, it shouldn't be translated, 
> so there the current behaviour would be expected.

I disagree here. I think a tree conflict should be flagged in this case.

Ideally the user would be presented with an interactive conflict
resolution prompt that helps with resolving the tree conflict.
But interactive conflict resolution for tree conflict is also still
on the TODO list.

> What I'm not sure is if this has an effect on mergeinfo, I haven't actually 
> tried that, so I'm guessing here.

Whatever happens to mergeinfo is a separate question.
We can define the way it should behave and then implement that.
We don't need to restrict ourselves by what merge-tracking currently
does in this particular case.

Re: svn: Error running context: APR does not understand this error code

[Nico Kadel-Garcia]

On Wed, Aug 10, 2011 at 7:26 PM, Kathy Khaghani wrote:

> I am very new to svn. I finally upgraded to subversion-1.6.17, running with
> apache : Apache/2.0.59 and openssl: Apache/2.0.59
>
> ** **
>
> First had to configure neon with “—with-ssl” option and then configure
> subversion with the following command:
>
> ./configure --prefix=/usr/local --with-neon --with-ssl
>
> Then make and make install off course.
>
> ** **
>
> First time I did a commit, seemed like it worked but gave me a warning :**
> **
>
> Warning: post-commit FS processing had error 'Can't remove
> '/users/repos/db/transactions/9208-1.txn''.
>
>
>

Looks like you've not been careful with ownership of the files or
directories in your repository, consistent with whatever serviceds you're
accessing it with. In particular, if you access with Apache, the
 /users/repo/db/ directory needs write access for the relevant apache user.
Isn't that "www-data". And frankly, Apache 2.0 is considered quite old a
tthis point. Why are you using it?



>
>
> After that all my commits are failing with the following error:
>
> ** **
>
> Transmitting file data ..svn: Commit failed (details follow):
>
> svn: Error running context: APR does not understand this error code
>
> ** **
>
> Again I have been googling all day today and nothing of any use. Would this
> be a bug with svn 1.6.17? or am I doing something wrong?
>
> ** **
>
> I would welcome any suggestions.
>
> ** **
>
> ** **
>
> *Kathy Khaghani**
> *Sr. Unix Admin
> Office 949.476.1180 x8414 • Fax 949.851.2756
>
> **
>
> *STEC, Inc. *|* The SSD Company**TM*
> NASDAQ STEC • Web www.stec-inc.com
>
> * *
>
> *[image: facebook-32x32.png]* *[image:
> twitter-32x32.png]* *[image:
> youtube-32x32.png]* *[image:
> linkedin-32x32.png]* *[image:
> wordpress-32x32.png]* *[image: 
> rss-32x32.png]*
> **
>
> ** **
>
> *PROPRIETARY-CONFIDENTIAL INFORMATION INCLUDED*
> This electronic transmission, and any documents attached hereto, may
> contain confidential, proprietary and/or legally privileged information. The
> information is intended only for use by the recipient named above. If you
> received this electronic message in error, please notify the sender and
> delete the electronic message. Any disclosure, copying, distribution, or use
> of the contents of information received in error is strictly prohibited, and
> violators will be pursued legally.
>   ­­
>
<><><><><><>

Re: Adding license text to files

[Jason Aubrey]

Thanks all for you very helpful suggestions.

Thanks again,
Jason

Parallel branches/tags/trunk directories

[Mike Cepek]

(I did some searching for an answer here and elsewhere, and didn't find it; 
sorry if I missed it.)
 
The project I'm dealing with has the SVN repository arranged like so:
 
proj/top1/branches/
proj/top1/tags/
proj/top1/trunk/
proj/top2/common/branches/
proj/top2/common/tags/
proj/top2/common/trunk/
proj/top2/thingA/branches/
proj/top2/thingA/tags/
proj/top2/thingA/trunk/
proj/top2/thingB/branches/
proj/top2/thingB/tags/
proj/top2/thingB/trunk/
proj/top2/deploy/common/branches/
proj/top2/deploy/common/tags/
proj/top2/deploy/common/trunk/
proj/top2/deploy/thingA/env1/branches/
proj/top2/deploy/thingA/env1/tags/
proj/top2/deploy/thingA/env1/trunk/
proj/top2/deploy/thingA/env2/branches/
proj/top2/deploy/thingA/env2/tags/
proj/top2/deploy/thingA/env2/trunk/
proj/top2/deploy/thingB/env1/branches/
proj/top2/deploy/thingB/env1/tags/
proj/top2/deploy/thingB/env1/trunk/
(etc)
 
First, I completely agree that this organization has issues.  Changing is isn't 
an option.  I'll spare you the details.  :-/
 
My question is:  how to checkout and update at the proj/ level without getting 
the content of all the tags/ and branches/ directories?
 
The "Sparse Directories" features of SVN (--depth and --set-depth) sounded good:
http://svnbook.red-bean.com/en/1.5/svn.advanced.sparsedirs.html
 
But those features are not sufficient.  In order to do a fresh checkout of the 
above and avoid the massive on-disk redundancy that would occur due to the 
content of tags/ and branches/, each trunk/ directory must be checked out 
individually.  Other than creating a brittle script that lists each trunk/ 
directory, I don't see a solution.  Even then, each branches/ and tags/ 
directory needs to be marked with --set-depth as well.
 
I also discovered that "svn co URL/proj/top1 --depth immediates" can take a 
very long time for a tree with tons of content.  Seems like a bug (using 
SlikSvn 1.6.15).  Similarly, something like "svn update URL/proj/top1/tags 
-depth immediates" would be handy at times to get just the empty 
subdirectories, named after each branch or tag.  Updating just one of those 
subdirectories would allow mass-diffs between the trunk or another branch/tag.  
I don't see why a depth-limited operation like that should take so much time.
 
I though about using 'svn list http://.../proj/' and grep'ing the result for 
"/trunk", but that one command takes over 10 minutes - not feasible.  A 
checkout of all the trunk/ directory contents only takes 2.5 minutes.
 
So: has anyone found a clean way to handle checkouts and updates when 
branches/tags/trunk directories are strewn all over a tree?  Thanks.

Parallel branches/tags/trunk directories

[Mike Cepek]

(resend as plaintext to fix formatting)
 
(I did some searching for an answer here and elsewhere, and didn't find it; 
sorry if I missed it.)

The project I'm dealing with has the SVN repository arranged like so:

proj/top1/branches/
proj/top1/tags/
proj/top1/trunk/
proj/top2/common/branches/
proj/top2/common/tags/
proj/top2/common/trunk/
proj/top2/thingA/branches/
proj/top2/thingA/tags/
proj/top2/thingA/trunk/
proj/top2/thingB/branches/
proj/top2/thingB/tags/
proj/top2/thingB/trunk/
proj/top2/deploy/common/branches/
proj/top2/deploy/common/tags/
proj/top2/deploy/common/trunk/
proj/top2/deploy/thingA/env1/branches/
proj/top2/deploy/thingA/env1/tags/
proj/top2/deploy/thingA/env1/trunk/
proj/top2/deploy/thingA/env2/branches/
proj/top2/deploy/thingA/env2/tags/
proj/top2/deploy/thingA/env2/trunk/
proj/top2/deploy/thingB/env1/branches/
proj/top2/deploy/thingB/env1/tags/
proj/top2/deploy/thingB/env1/trunk/
(etc)

First, I completely agree that this organization has issues.  Changing is isn't 
an option.  I'll spare you the details.  :-/

My question is:  how to checkout and update at the proj/ level without getting 
the content of all the tags/ and branches/ directories?

The "Sparse Directories" features of SVN (--depth and --set-depth) sounded good:
http://svnbook.red-bean.com/en/1.5/svn.advanced.sparsedirs.html

But those features are not sufficient.  In order to do a fresh checkout of the 
above and avoid the massive on-disk redundancy that would occur due to the 
content of tags/ and branches/, each trunk/ directory must be checked out 
individually.  Other than creating a brittle script that lists each trunk/ 
directory, I don't see a solution.  Even then, each branches/ and tags/ 
directory needs to be marked with --set-depth as well.

I also discovered that "svn co URL/proj/top1 --depth immediates" can take a 
very long time for a tree with tons of content.  Seems like a bug (using 
SlikSvn 1.6.15).  Similarly, something like "svn update URL/proj/top1/tags 
-depth immediates" would be handy at times to get just the empty 
subdirectories, named after each branch or tag.  Updating just one of those 
subdirectories would allow mass-diffs between the trunk or another branch/tag.  
I don't see why a depth-limited operation like that should take so much time.

I though about using 'svn list http://.../proj/'; and grep'ing the result for 
"/trunk", but that one command takes over 10 minutes - not feasible.  A 
checkout of all the trunk/ directory contents only takes 2.5 minutes.

So: has anyone found a clean way to handle checkouts and updates when 
branches/tags/trunk directories are strewn all over a tree?  Thanks.

RE: Problems compiling 1.7.0 on redhat el4 64bit

[michael_rytting]

I tried running -O2 and -O1, both were crashing as well.  Only completely 
disabling optimizations will cause the segfault to stop.

-Original Message-
From: David Chapman [mailto:dcchap...@acm.org] 
Sent: Wednesday, August 10, 2011 5:39 PM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: philip.mar...@wandisco.com; markp...@gmail.com; d...@subversion.apache.org; 
users@subversion.apache.org
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit

On 8/10/2011 4:12 PM, michael_rytt...@agilent.com wrote:
> It is set to 1
>
> On Aug 10, 2011, at 3:51 PM, "Philip Martin"  
> wrote:
>
>>   writes:
>>
>>> If I disable optimizations by doing "make CFLAGS=-O0" the program no 
>>> longer crashes.
>> That suggests it could be a compiler bug.

Sorry to jump in so late, but I had significant problems with optimization for 
64-bit executables under CentOS 4.x.  If you can't upgrade, I suggest dialing 
down the optimization flags.  I had to drop from -O3 to -O2 so that Crypto++ 
5.5.2 would run, for example.  At some point I could drop support for 
RHEL/CentOS 4.x from my client's products and try going back to -O3, but the 
required testing hasn't been real high on the priority list.

Assuming the SVN configuration scripts can distinguish between the releases, I 
suspect that changing the default optimization flags for RHEL 4.x will be 
simpler than trying to fix the new UTF-8 code.  Have you tried intermediate 
levels of optimization?  We went to production with -O2, so it's not as if all 
64-bit optimizations were broken.

-- 
 David Chapman dcchap...@acm.org
 Chapman Consulting -- San Jose, CA

RE: Problems compiling 1.7.0 on redhat el4 64bit

[michael_rytting]

> > I'm using gcc.  The default in the makefile.
> 
> I think RHEL may have come with two different gcc, a 3 series and a 4 series. 
>  What version does 'gcc -v' show?

3.4.6

> It would be good to confirm that at runtime you really are using the version 
> of libapr you compiled, run ldd on the svn executable.

If it wasn't, changing the optimization level shouldn't have made a difference. 
 That being said, ldd reports that I am using the correct version.

libapr-1.so.0 => /cos/home/ryttingm/local/lib/libapr-1.so.0 (0x002a967b5000)

-Mike

RE: Problems compiling 1.7.0 on redhat el4 64bit

[michael_rytting]

No luck with that option, still crashing.

-Original Message-
From: Philip Martin [mailto:philip.mar...@wandisco.com] 
Sent: Wednesday, August 10, 2011 4:20 PM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: markp...@gmail.com; d...@subversion.apache.org; users@subversion.apache.org
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit

Philip Martin  writes:

>  writes:
>
>> If I disable optimizations by doing "make CFLAGS=-O0" the program no 
>> longer crashes.
>
> That suggests it could be a compiler bug.

The other flag you could try is to enable optimisation but to use 
-fno-strict-aliasing.

--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com

Re: Merging copy operations

[Ulrich Eckhardt]

On Wednesday 10 August 2011, Johan Corveleyn wrote:
> I think what you're describing is issue #2685:
> 
> http://subversion.tigris.org/issues/show_bug.cgi?id=2685 (Move + Merge
> => lose modifications)

Yes, this is exactly what I was stumbling over.

Thanks to Andreas and Stefan, too, that explains the issue.

Uli
**
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
Visit our website at http://www.dominolaser.com
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

the revision number and a tag

[Michael Hüttermann]

Hello,

given a Subversion tag, what's the best way to get the revision number 
of that tag, i.e. the revision number with which the tag was created? Is 
it possible at all having checked out the tag to a local working copy? 
Or is there any other way to cross-reference a "tag" to a revision 
number?



Thanks.


Michael

Re: the revision number and a tag

[Giulio Troccoli]

On 11/08/11 16:59, Michael Hüttermann wrote:


Hello,

given a Subversion tag, what's the best way to get the revision number 
of that tag, i.e. the revision number with which the tag was created? 
Is it possible at all having checked out the tag to a local working 
copy? Or is there any other way to cross-reference a "tag" to a 
revision number?



Thanks.


Michael



I think svn log --limit 1 would work. It will give you the last log when 
the tag was modified. Since a tag should never be modified that log 
should refer to the copy


G

Re: the revision number and a tag

[Giulio Troccoli]

On 11/08/11 17:02, Giulio Troccoli wrote:



On 11/08/11 16:59, Michael Hüttermann wrote:


Hello,

given a Subversion tag, what's the best way to get the revision 
number of that tag, i.e. the revision number with which the tag was 
created? Is it possible at all having checked out the tag to a local 
working copy? Or is there any other way to cross-reference a "tag" to 
a revision number?



Thanks.


Michael



I think svn log --limit 1 would work. It will give you the last log 
when the tag was modified. Since a tag should never be modified that 
log should refer to the copy


G


Obviously there will need to be some parsing of the output if you want 
just the revision number (to be used in a script for example)

RE: Parallel branches/tags/trunk directories

[Bob Archer]

> (resend as plaintext to fix formatting)
> 
> (I did some searching for an answer here and elsewhere, and didn't find it;
> sorry if I missed it.)
> 
> The project I'm dealing with has the SVN repository arranged like so:
> 
> proj/top1/branches/
> proj/top1/tags/
> proj/top1/trunk/
> proj/top2/common/branches/
> proj/top2/common/tags/
> proj/top2/common/trunk/
> proj/top2/thingA/branches/
> proj/top2/thingA/tags/
> proj/top2/thingA/trunk/
> proj/top2/thingB/branches/
> proj/top2/thingB/tags/
> proj/top2/thingB/trunk/
> proj/top2/deploy/common/branches/
> proj/top2/deploy/common/tags/
> proj/top2/deploy/common/trunk/
> proj/top2/deploy/thingA/env1/branches/
> proj/top2/deploy/thingA/env1/tags/
> proj/top2/deploy/thingA/env1/trunk/
> proj/top2/deploy/thingA/env2/branches/
> proj/top2/deploy/thingA/env2/tags/
> proj/top2/deploy/thingA/env2/trunk/
> proj/top2/deploy/thingB/env1/branches/
> proj/top2/deploy/thingB/env1/tags/
> proj/top2/deploy/thingB/env1/trunk/
> (etc)
> 
> First, I completely agree that this organization has issues.  Changing is 
> isn't an
> option.  I'll spare you the details.  :-/
> 
> My question is:  how to checkout and update at the proj/ level without
> getting the content of all the tags/ and branches/ directories?
> 
> The "Sparse Directories" features of SVN (--depth and --set-depth) sounded
> good:
> http://svnbook.red-bean.com/en/1.5/svn.advanced.sparsedirs.html
> 
> But those features are not sufficient.  In order to do a fresh checkout of the

Not "sufficient" because it takes time and manual work to do? Or, because it 
doesn't do what you need? Sparse directories is exactly what you need to use to 
get what you want.

1.7 added a -parents (I think it is) argument to the update/checkout so that 
you didn't have to do

Svn checkout ^/proj --depth empty
Cd proj
Svn checkout ^/proj/top1 --depth empty
Cd top1
Svn checkout ^/proj/top1/trunk 
Etc...

Also, if you are on Windows tortoiseSVN makes the above easier without the need 
to walking the path... iirc.

That all said, I don't really see the benefit of having one working copy that 
you can update at once. I prefer to check out the branch and/or trunks that I 
need to work on as needed and update each one as needed. If you want to update 
all your working copies with one command you can create a local batch file 
which goes through and calls update on each folder.

> above and avoid the massive on-disk redundancy that would occur due to
> the content of tags/ and branches/, each trunk/ directory must be checked
> out individually.  Other than creating a brittle script that lists each trunk/
> directory, I don't see a solution.  Even then, each branches/ and tags/
> directory needs to be marked with --set-depth as well.
> 
> I also discovered that "svn co URL/proj/top1 --depth immediates" can take a
> very long time for a tree with tons of content.  Seems like a bug (using 
> SlikSvn
> 1.6.15).  Similarly, something like "svn update URL/proj/top1/tags -depth
> immediates" would be handy at times to get just the empty subdirectories,
> named after each branch or tag.  Updating just one of those subdirectories
> would allow mass-diffs between the trunk or another branch/tag.  I don't see
> why a depth-limited operation like that should take so much time.

What version of the server are you running? I think if you use Sparse 
directories with a pre 1.6 server the server sends all the files and the client 
just throws away what doesn't fit into your requested depth.

BOb


> 
> I though about using 'svn list http://.../proj/'; and grep'ing the result for
> "/trunk", but that one command takes over 10 minutes - not feasible.  A
> checkout of all the trunk/ directory contents only takes 2.5 minutes.
> 
> So: has anyone found a clean way to handle checkouts and updates when
> branches/tags/trunk directories are strewn all over a tree?  Thanks.

Re: the revision number and a tag

[Andy Levy]

On Thu, Aug 11, 2011 at 12:02, Giulio Troccoli
 wrote:
>
>
> On 11/08/11 16:59, Michael Hüttermann wrote:
>>
>> Hello,
>>
>> given a Subversion tag, what's the best way to get the revision number of
>> that tag, i.e. the revision number with which the tag was created? Is it
>> possible at all having checked out the tag to a local working copy? Or is
>> there any other way to cross-reference a "tag" to a revision number?
>>
>>
>> Thanks.
>>
>>
>> Michael
>>
>
> I think svn log --limit 1 would work. It will give you the last log when the
> tag was modified. Since a tag should never be modified that log should refer
> to the copy

That or svn log --stop-on-copy.

If you use svn log -v --stop-on-copy, the list of changed paths (the
copy destination) will be given, in addition to the source path and
its revision. Parse that out and you're set. You'll have both the
revision which created the tag and the latest revision of the path the
tag came from.

Re: the revision number and a tag

[Andy Levy]

On Thu, Aug 11, 2011 at 12:13, Andy Levy  wrote:
> On Thu, Aug 11, 2011 at 12:02, Giulio Troccoli
>  wrote:
>>
>>
>> On 11/08/11 16:59, Michael Hüttermann wrote:
>>>
>>> Hello,
>>>
>>> given a Subversion tag, what's the best way to get the revision number of
>>> that tag, i.e. the revision number with which the tag was created? Is it
>>> possible at all having checked out the tag to a local working copy? Or is
>>> there any other way to cross-reference a "tag" to a revision number?
>>>
>>>
>>> Thanks.
>>>
>>>
>>> Michael
>>>
>>
>> I think svn log --limit 1 would work. It will give you the last log when the
>> tag was modified. Since a tag should never be modified that log should refer
>> to the copy
>
> That or svn log --stop-on-copy.
>
> If you use svn log -v --stop-on-copy, the list of changed paths (the
> copy destination) will be given, in addition to the source path and
> its revision. Parse that out and you're set. You'll have both the
> revision which created the tag and the latest revision of the path the
> tag came from.
>

I hit Send too early.

If no one has modified the tag, --limit 1 would yield the same results
as --stop-on-copy. But if someone *has* modified the tag (which we
agree shouldn't happen, but depending on your setup, it could - that's
a whole other matter), that modification will appear instead of the
copy which created the tag. If you use --stop-on-copy, you can detect
this condition and the oldest log will end up being the creation of
the tag.

Re: the revision number and a tag

[Mark Phippard]

On Thu, Aug 11, 2011 at 11:59 AM, Michael Hüttermann <
mich...@huettermann.net> wrote:

>
> given a Subversion tag, what's the best way to get the revision number of
> that tag, i.e. the revision number with which the tag was created? Is it
> possible at all having checked out the tag to a local working copy? Or is
> there any other way to cross-reference a "tag" to a revision number?
>

Simple way is just to use svn info and look for the Last Changed Revision:

$ svn info http://svn.apache.org/repos/asf/subversion/tags/1.6.17
Path: 1.6.17
URL: http://svn.apache.org/repos/asf/subversion/tags/1.6.17
Repository Root: http://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1156659
Node Kind: directory
Last Changed Author: hwright
Last Changed Rev: 1130806
Last Changed Date: 2011-06-02 16:49:07 -0400 (Thu, 02 Jun 2011)


-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Discrepancy in SNAPSHOT jar filename between JAR Plugin and Assembly Plugin

[Michael Remijan]

I am seeing an interesting discrepancy between the JAR plugin and the Assembly 
plugin.  

I have the JAR plugin configured to add the dependencies to the MANIFEST:

    
    org.apache.maven.plugins
    maven-jar-plugin
      
   
   
   true
   lib
   org.myapp.main.Main
       
   
    
    

The JAR file name will be added to the MANIFEST like this. . .

        Class-Path: lib/my-commons-1.0.6-SNAPSHOT.jar [...etc]

So far so good.

Now, I have the Assembly plugin configured to add the dependencies to the /lib 
directory of an archive:




    
    
    false
    /lib
    true
    
    


When the Assembly plugin builds the archive, the name of the jarfile is NOT 
my-commons-1.0.6-SNAPSHOT.jar!  Instead what I get is 
"my-commons-1.0.6-20110810.204640-23.jar"


$ ll my-commons*
-rwx--+ 1 mike Users Users 48805 Aug 11 08:53 
my-commons-1.0.6-20110810.204640-23.jar

Major Problem!! 

Anyone know why this is happening?  I am using Maven 2.0.9 and I'm stuck with 
this version and cannot change it!

Re: Discrepancy in SNAPSHOT jar filename between JAR Plugin and Assembly Plugin

[Ryan Schmidt]

On Aug 11, 2011, at 11:34, Michael Remijan wrote:

> I am seeing an interesting discrepancy between the JAR plugin and the 
> Assembly plugin.  

This message doesn't relate to the "revision number and a tag" thread to which 
you replied. Please always create a new message (not a reply) when you have a 
new topic to discuss.

http://subversion.apache.org/docs/community-guide/mailing-lists.html#fresh-post

Re: Parallel branches/tags/trunk directories

[Mike Cepek]

> Not "sufficient" because it takes time and manual work to do? Or, because it 
> doesn't do what you need?

Taking 97 minutes to pull 25 GB from all the tags/ and branches/ is 
unacceptable when it takes only 3 minutes to pull the 660 MB we actually need 
from just the trunk/ directories.  Getting everything and then manually pruning 
isn't a viable option.  Getting just the trunk/ directories without a brittle 
script is the whole point of my post.

> Sparse directories is exactly what you need to use to get what you want.
> 1.7 added a -parents (I think it is) argument to the update/checkout [...]
I'll check out that option.  Unfortunately...

> What version of the server are you running? I think if you use Sparse 
> directories with a pre 1.6 server
> the server sends all the files and the client just throws away what doesn't 
> fit into your requested depth.

Ah.  Our server reports itself as 1.4.2.  That probably explains why it took so 
long.  I have no idea what the odds are of having our server upgraded (used by 
many other projects).

> That all said, I don't really see the benefit of having one working copy that 
> you can update at once.

As opposed to having 14 working copies that every developer has to manually 
maintain?  Really?  The layout in my OP is only part of this project.  We 
really do have 14 separate branches/tags/trunks trees.  This is a new project, 
so that number will probably go up over time.

> I prefer to check out the branch and/or trunks that I need to work on as 
> needed and update each
> one as needed. If you want to update all your working copies with one command 
> you can create
> a local batch file which goes through and calls update on each folder.

With --max-depth it should be possible to avoid needing a script for updates.  
I've been working on a script for the initial checkout. It's non-trivial and 
brittle.  I will postpone the gory details unless there is interest.

Re: Parallel branches/tags/trunk directories

[Andreas Krey]

On Thu, 11 Aug 2011 07:52:46 +, Mike Cepek wrote:
...
> But those features are not sufficient.  In order to do a fresh checkout of 
> the above and avoid the massive on-disk redundancy that would occur due to 
> the content of tags/ and branches/, each trunk/ directory must be checked out 
> individually. 

There already were comments on the usefulness of a complete checkout. I
mainly find (resp. found, in the days of CVS, without the path-emulated
tags/branches) it helpful to be able to search the whole repo for usages
of my APIs.

Anyway, one way to not have to script this would be to have a separate
tree that pulls in all the interesting parts as svn:externals. That way,
you get easy updates; in exchange for needing some care when committing.
(I don't suppose you actually *want* the ../trunk/.. in the paths?)

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Parallel branches/tags/trunk directories

[Andy Levy]

On Thu, Aug 11, 2011 at 13:07, Mike Cepek  wrote:

>> What version of the server are you running? I think if you use Sparse 
>> directories with a pre 1.6 server
>> the server sends all the files and the client just throws away what doesn't 
>> fit into your requested depth.
>
> Ah.  Our server reports itself as 1.4.2.  That probably explains why it took 
> so long.  I have no idea what the odds are of having our server upgraded 
> (used by many other projects).

You're on a very old, unsupported release. That should be a very
strong influence in getting the system upgraded to a newer version (or
stand up a new server & migrate projects as schedules allow). The
farther you fall behind, the more painful your upgrade path will
become (this is true for almost all software).

I'm trying to find the documentation (release notes, CHANGES file) to
corroborate Bob's description of how Sparse Directories work with
pre-1.6 servers, but I can't. I have the same recollection he does -
that you're still downloading everything and just discarding the items
that don't match the depth you've set. I see the same behavior with my
1.5.2 server and 1.6 clients.

Re: Parallel branches/tags/trunk directories

[kmradke]

Mike Cepek  wrote on 08/11/2011 12:07:44 PM:
> > Not "sufficient" because it takes time and manual work to do? Or, 
> because it doesn't do what you need?
> 
> Taking 97 minutes to pull 25 GB from all the tags/ and branches/ is 
> unacceptable when it takes only 3 minutes to pull the 660 MB we 
> actually need from just the trunk/ directories.  Getting everything 
> and then manually pruning isn't a viable option.  Getting just the 
> trunk/ directories without a brittle script is the whole point of my 
post.
> 
> > Sparse directories is exactly what you need to use to get what you 
want.
> > 1.7 added a -parents (I think it is) argument to the update/checkout 
[...]
> I'll check out that option.  Unfortunately...
> 
> > What version of the server are you running? I think if you use 
> Sparse directories with a pre 1.6 server
> > the server sends all the files and the client just throws away 
> what doesn't fit into your requested depth.
> 
> Ah.  Our server reports itself as 1.4.2.  That probably explains why
> it took so long.  I have no idea what the odds are of having our 
> server upgraded (used by many other projects).
> 
> > That all said, I don't really see the benefit of having one 
> working copy that you can update at once.
> 
> As opposed to having 14 working copies that every developer has 
> to manually maintain?  Really?  The layout in my OP is only part of 
> this project.  We really do have 14 separate branches/tags/trunks 
> trees.  This is a new project, so that number will probably go up over 
time.
> 
> > I prefer to check out the branch and/or trunks that I need to work
> on as needed and update each
> > one as needed. If you want to update all your working copies with 
> one command you can create
> > a local batch file which goes through and calls update on each folder.
> 
> With --max-depth it should be possible to avoid needing a script for
> updates.  I've been working on a script for the initial checkout. 
> It's non-trivial and brittle.  I will postpone the gory details 
> unless there is interest.

How about creating a separate directory that only contains a bunch of
svn:externals values to each trunk dir you need?  Then the user
just checks out this one directory which will automatically
pull only the directories you want.

I don't normally recommend externals since each external causes
a separate connection to the server.  This can be a big performance
problem for high latency connections...  Especially when it
is abused by having thousands of externals...

Kevin R.

Re: Parallel branches/tags/trunk directories

[Les Mikesell]

On 8/11/2011 12:07 PM, Mike Cepek wrote:



What version of the server are you running? I think if you use Sparse 
directories with a pre 1.6 server
the server sends all the files and the client just throws away what doesn't fit 
into your requested depth.


Ah.  Our server reports itself as 1.4.2.  That probably explains why it took so 
long.  I have no idea what the odds are of having our server upgraded (used by 
many other projects).


The likely reason for having one that old is that it was what was 
included in a Red Hat or CentOS distribution and you haven't done a 
system update recently (or it is older than the 5.x version).  If it is 
a 5.x, there are plenty of good reasons to update it, including bringing 
subversion up to a usable 1.6.x.



That all said, I don't really see the benefit of having one working copy that 
you can update at once.


As opposed to having 14 working copies that every developer has to manually 
maintain?  Really?  The layout in my OP is only part of this project.  We 
really do have 14 separate branches/tags/trunks trees.  This is a new project, 
so that number will probably go up over time.


Why can't you build your own unversioned top level tree and check out 
the parts you want in the places they should be underneath it?  A script 
to do that shouldn't be any harder than loading the right pieces under a 
sparse tree and you can jump around in the branches with svn switch.  Or 
build a versioned tree that uses externals to pull what you want. All 
you lose is the ability to do a single top-level commit when you have 
changes in multiple components.


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

Re: Parallel branches/tags/trunk directories

[Stefan Sperling]

On Thu, Aug 11, 2011 at 07:18:46PM +0200, Andreas Krey wrote:
> There already were comments on the usefulness of a complete checkout. I
> mainly find (resp. found, in the days of CVS, without the path-emulated
> tags/branches) it helpful to be able to search the whole repo for usages
> of my APIs.

For this purpose there are solutions which perform data-mining directly
on the repository and provide full-text search of all files in all
revisions via a web interface.  Examples are svnsearch (open source)
and fisheye (proprietary).

Re: Parallel branches/tags/trunk directories

[Mike Cepek]

I appreciate the creative solutions, but I feel that we may be wandering a bit 
off track.
 
This SVN repository layout will NOT be changing.  Mapping externals to every 
trunk/ directory seems like overkill, especially when features like --max-depth 
exist.
 
What little I've been able to find out about --parents suggests that it isn't 
going to be much of a help.  It sound like it just simplifies having to deal 
with intermediate directories.  That might simplify my checkout script a bit, 
but not much.  And since SVN 1.7 appears to be bleeding-edge, I expect any SVN 
server upgrade I can initiate will be to 1.6 anyway.
 
If there's interest, I can post the bash shell script I'm working on that does 
most of the job of a full trunk-only checkout.  Since it's mostly just SVN 
commands, it's likely that we'll migrate this into Ant eventually.  I'm not 
happy about how brittle this script is, and I can't fully optimize it due to my 
ancient SVN server version.  But I'll share my half-baked script if anyone 
cares.
 
Otherwise, it sounds like there is no consensus solution for dealing with this 
kind of repository layout.  Thanks, all.

Re: Parallel branches/tags/trunk directories

[Les Mikesell]

On 8/11/2011 1:25 PM, Mike Cepek wrote:

I appreciate the creative solutions, but I feel that we may be wandering a bit 
off track.


They mostly aren't 'creative' - just standard practices.


Otherwise, it sounds like there is no consensus solution for dealing with this 
kind of repository layout.  Thanks, all.


No, it is pretty common for people to pull in an assortment of 
components from different locations in a repository and to choose from a 
large number of branches.  Your only odd part is arranging things so 
that you have to do it even for the main portions of the project.


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

RE: Parallel branches/tags/trunk directories

[Bob Archer]

> > Not "sufficient" because it takes time and manual work to do? Or, because
> it doesn't do what you need?
> 
> Taking 97 minutes to pull 25 GB from all the tags/ and branches/ is
> unacceptable when it takes only 3 minutes to pull the 660 MB we actually
> need from just the trunk/ directories.  Getting everything and then manually
> pruning isn't a viable option.  Getting just the trunk/ directories without a
> brittle script is the whole point of my post.
> 
> > Sparse directories is exactly what you need to use to get what you want.
> > 1.7 added a -parents (I think it is) argument to the update/checkout
> > [...]
> I'll check out that option.  Unfortunately...
> 
> > What version of the server are you running? I think if you use Sparse
> > directories with a pre 1.6 server the server sends all the files and the 
> > client
> just throws away what doesn't fit into your requested depth.
> 
> Ah.  Our server reports itself as 1.4.2.  That probably explains why it took 
> so
> long.  I have no idea what the odds are of having our server upgraded (used
> by many other projects).
> 
> > That all said, I don't really see the benefit of having one working copy 
> > that
> you can update at once.
> 
> As opposed to having 14 working copies that every developer has
> to manually maintain?  Really?  The layout in my OP is only part of this
> project.  We really do have 14 separate branches/tags/trunks trees.  This is a
> new project, so that number will probably go up over time.

Yes really. I have perhaps 20 or more working copies checked out. Many of those 
are various versions (branches) of one project. I update the ones I am working 
on as needed. I have no need to update WC's that I'm not working on every time 
I update the stuff I am working on. Once again, I don't see the benefit. 

BOb


> 
> > I prefer to check out the branch and/or trunks that I need to work on
> > as needed and update each one as needed. If you want to update all
> > your working copies with one command you can create a local batch file
> which goes through and calls update on each folder.
> 
> With --max-depth it should be possible to avoid needing a script for
> updates.  I've been working on a script for the initial checkout. It's 
> non-trivial
> and brittle.  I will postpone the gory details unless there is interest.

Re: Parallel branches/tags/trunk directories

[David Weintraub]

Okay solutions:

Since you're dealing with an older version of Subversion, you might
find the -N (no-recursive) flag to work better than --depth. Do a "svn
co -N" and then go into each of those directories and do a "svn update
-N" unless those directories are branches or tags (you skip) or is
trunk (you update without the -N flag).

Maybe something like this might work out better for you. Use "svn ls
-R" and find the directories you have to checkout:

svn ls -R http://myserver/svn/proj | grep "/trunk/$"

That's probably faster than using "svn co --depths" a bunch of times.
You can then use that list to checkout each of those directories in
their own working directory. You'll have a dozen working directories.
to get a listing of all the trunks you have to checkout, and then
checking out each trunk in its own directory independently of the
others. It might work better than checking out proj in a sparse
checkout and working your way down to all of the trunks.

Completely untested, but you get the idea:

svn ls -R $URL | grep "/trunk/$" | while read directory
do
parent=$(dirname $directory)
mkdir -p $parent
svn co $URL/$directory $directory
done

-- 
David Weintraub
qazw...@gmail.com

RE: updates on subdirectories : revision not being pulled

[Igor DEFAYE]

Hello,

 

Thanks for your prompt reply. Unfortunately your email landed in the spam 
folder of our mail server, so I only got it today when the admin looked in the 
spam folder.

 

What you say would explain what we see on the change log. Even though I find 
really it confusing that in this case some revisions are deleted from the 
changelog on subdirectories and not on higher directories. It's not consistent.

 

Anyhow, may be this was not a good example after all, but that was the only 
visible case so far that showed something to explain the problem we face.

 

We have other cases of update not happening and when committing the files are 
replaced with older versions. We will look deeper into the problem to try to 
find some explanations of what happens. We had a lot of bug regressions lately, 
it was just code that had disappeared, as if a revision was removed. Those that 
committed the files that 'reverted' the code had no conflicts or warning 
whatsoever from svn.

 

If you know anything that could cause this kind of problem, bad server 
configuration, svn client problem, etc... I would be happy to hear about it so 
we can resolve this issue.

 

Thanks in advance,

 

Igor Defaye

Development Team Manager. 

Site Alpha Group Planon

 

 

De : Mark Phippard [mailto:markp...@gmail.com] 
Envoyé : 9 août 2011 14:32
À : Igor DEFAYE
Cc : users@subversion.apache.org
Objet : Re: updates on subdirectories : revision not being pulled

 

On Tue, Aug 9, 2011 at 1:57 PM, Igor DEFAYE  wrote:

 

We have a major problem on our Apache Subversion. When updating some 
revisions are not pulled down to the pc, regardless of which pc we use.

This seems to happen only when updating from a sub-directory and not 
updating from root directory, but it might also happen from root dir, I've just 
haven't seen it happen yet.

I don't know if this is an already known issue, or if I need to submit 
a new one. So I hope someone can help me look rapidly over this.

 

Our server is up to date : 1.6.17 build 2190.74 . We administer the 
server via Collabnet Subversion Edge. We mostly use tortoise svn clients, they 
were updated but the problem is server side.

 

We have noticed the revisions that are not pulled down to the pcs also 
do not appear in the change log on the subdirectory, but does on higher 
directories. 

 

May be an example will make it clearer  :

On root directory we see the change log for revision 20445, it concerns 
only one file : /SuiteFM_dot_Net/Bin/www/ope_RAPPORT/js/container.js

Both Collabnet or tortoise show the same, so far so good.

 

Please do not mail dev@.  This is not a discussion about the development of 
Subversion.

 

Based on your screenshots, I would suggest you look at revision 20453.  If 
someone replaced the folder in that commit with an earlier version from its 
history than everything in your screenshots makes perfect sense.  Basically @ 
revision 20453, the folder was replaced, creating a new line of history that 
does not include those other revisions.

 

 

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

RE: updates on subdirectories : revision not being pulled

[Igor DEFAYE]

 

 

De : Igor DEFAYE 
Envoyé : 11 août 2011 17:26
À : 'Mark Phippard '
Cc : 'users@subversion.apache.org'
Objet : RE: updates on subdirectories : revision not being pulled

 

Hello,

 

Thanks for your prompt reply. Unfortunately your email landed in the spam 
folder of our mail server, so I only got it today when the admin looked in the 
spam folder.

 

What you say would explain what we see on the change log. Even though I find 
really it confusing that in this case some revisions are deleted from the 
changelog on subdirectories and not on higher directories. It's not consistent.

 

Anyhow, may be this was not a good example after all, but that was the only 
visible case so far that showed something to explain the problem we face.

 

We have other cases of update not happening and when committing the files are 
replaced with older versions. We will look deeper into the problem to try to 
find some explanations of what happens. We had a lot of bug regressions lately, 
it was just code that had disappeared, as if a revision was removed. Those that 
committed the files that 'reverted' the code had no conflicts or warning 
whatsoever from svn.

 

If you know anything that could cause this kind of problem, bad server 
configuration, svn client problem, etc... I would be happy to hear about it so 
we can resolve this issue.

 

Thanks in advance,

 

Igor Defaye

Development Team Manager. 

Site Alpha Group Planon

 

 

De : Mark Phippard [mailto:markp...@gmail.com] 
Envoyé : 9 août 2011 14:32
À : Igor DEFAYE
Cc : users@subversion.apache.org
Objet : Re: updates on subdirectories : revision not being pulled

 

On Tue, Aug 9, 2011 at 1:57 PM, Igor DEFAYE  wrote:

 

We have a major problem on our Apache Subversion. When updating some 
revisions are not pulled down to the pc, regardless of which pc we use.

This seems to happen only when updating from a sub-directory and not 
updating from root directory, but it might also happen from root dir, I've just 
haven't seen it happen yet.

I don't know if this is an already known issue, or if I need to submit 
a new one. So I hope someone can help me look rapidly over this.

 

Our server is up to date : 1.6.17 build 2190.74 . We administer the 
server via Collabnet Subversion Edge. We mostly use tortoise svn clients, they 
were updated but the problem is server side.

 

We have noticed the revisions that are not pulled down to the pcs also 
do not appear in the change log on the subdirectory, but does on higher 
directories. 

 

May be an example will make it clearer  :

On root directory we see the change log for revision 20445, it concerns 
only one file : /SuiteFM_dot_Net/Bin/www/ope_RAPPORT/js/container.js

Both Collabnet or tortoise show the same, so far so good.

 

Please do not mail dev@.  This is not a discussion about the development of 
Subversion.

 

Based on your screenshots, I would suggest you look at revision 20453.  If 
someone replaced the folder in that commit with an earlier version from its 
history than everything in your screenshots makes perfect sense.  Basically @ 
revision 20453, the folder was replaced, creating a new line of history that 
does not include those other revisions.

 

 

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Problems compiling 1.7.0 on redhat el4 64bit

[Blair Zajac]

On Aug 11, 2011, at 8:32 AM,  
 wrote:

> No luck with that option, still crashing.

Try running the process under valgrind to see if it finds anything.

Blair

Re: Parallel branches/tags/trunk directories

[Ryan Schmidt]

On Aug 11, 2011, at 12:21, Andy Levy wrote:

> I'm trying to find the documentation (release notes, CHANGES file) to
> corroborate Bob's description of how Sparse Directories work with
> pre-1.6 servers, but I can't. I have the same recollection he does -
> that you're still downloading everything and just discarding the items
> that don't match the depth you've set. I see the same behavior with my
> 1.5.2 server and 1.6 clients.

http://subversion.apache.org/docs/release-notes/1.5.html#sc-compat

Re: Parallel branches/tags/trunk directories

[Mike Cepek]

> Maybe something like this might work out better for you. Use "svn ls -R"
> and find the directories you have to checkout:

> svn ls -R http://myserver/svn/proj | grep "/trunk/$"

Thanks, David.  I did bring up using 'svn list' in my original post and 
grep'ing for trunk, but that took 4 times as long as the actual checkouts that 
need to be performed.  And even a 1.6 server won't improve that.

I've started the ball rolling on an SVN server upgrade.  Without that, I don't 
see any feasible non-brittle solution.  With that, I'm thinking that iterating 
N levels deep with "--depth immediates" will be performant.  I'm not sure how 
Ant does at emulating 'find . -type d' command...

@Bob Archer:  Yes, I've had dozens of SVN sandboxes on-disk at once both inside 
and outside of Eclipse.  They too were various versions of projects.  I 
strongly suspect our situation is different.  This one project has different 
branches and tags at different levels.  In fact, our production support team 
will be mainly responsible for the proj/top2/deploy/** subtree, including 
tagging, whereas the other trees will be managed by us product developers.  I 
suspect there will be at least 5 different "sets" of trunk/tag/branch trees, 
updated at different times, some perhaps with different naming conventions (for 
branches and tags).

Re: Parallel branches/tags/trunk directories

[Mike Cepek]

> I'll bite...
> Why do you need to checkout everything from the "proj" level of the
> tree? If it is common to checkout from the project level of the tree,
> how do you branch or tag if you have to branch and tag each and every
> directory?


Sorry, I missed this earlier reply.  You identify good issues, David, and I've 
raised them.  I think it's one of those things where I can see the issues 
before others do, and until the pain becomes theirs personally, there's no 
point in trying.

> proj/trunk|tags|branches/*

I've used that project layout in all my past projects with SVN, CVS, ... sccs 
(yes, way back).  In this particular project, the sets of deploy/ directories 
will be managed separately by another team.

My attempt at anonymization unfortunately obfuscated the layout a bit.  I can 
see reasons for a layout like this in our case:

proj/common/trunk|tags|branches
proj/top[1|2]/trunk|tags|branchesproj/deploy/common/trunk|tags|branches

proj/deploy/top[1|2]/trunk|tags|branches/env[1-9]
The codebase resides in the first trees, and runtime configuration (deploy) 
stuff in the latter ones.  The top1/ and top2/ projects evolve independently, 
but share the common/ stuff.

I agree that SVN makes adjusting this pretty simple.  I hope we have that 
opportunity before the concrete hardens too much more.  Thanks.

Subversion on Drupal

[Andy Canfield]

My goal in learning Subversion was to put our web site under version 
control. Now I have my doubts as to whether Subversion can handle it.


The web site uses Drupal. And Drupal has the characteristic that much of 
the site is contained in a MySQL database. For example, if I install a 
module and set it up, the module is a disk file, but the configuration 
of that module is in the database. If I make a change, part of the 
change may be in a PHP code file on disk, part may be in the database. 
The database contains both user data and configuration data, intermingled.


I could get Subversion to work. I would have a pre-commit script to back 
up the database to a disk file in the working copy. I would have a 
post-checkout script to reload the database from the disk file. Along 
with svn commit and svn checkout, this would give us the ability to roll 
back to any earlier version.


What I can not imagine is how to get more than one person to be able to 
work on the site. Yes, Subversion would be able to merge changes to the 
disk files. But I don't see how Subversion can handle merging changes to 
the database. The MySQL database is text; perhaps someone here as 
experience with that. Can MySQL backup files be merged?

Re: Subversion on Drupal

[Geoff Hoffman]

On Thu, Aug 11, 2011 at 7:56 PM, Andy Canfield wrote:

> My goal in learning Subversion was to put our web site under version
> control. Now I have my doubts as to whether Subversion can handle it.
>
> The web site uses Drupal. And Drupal has the characteristic that much of
> the site is contained in a MySQL database. For example, if I install a
> module and set it up, the module is a disk file, but the configuration of
> that module is in the database. If I make a change, part of the change may
> be in a PHP code file on disk, part may be in the database. The database
> contains both user data and configuration data, intermingled.
>
> I could get Subversion to work. I would have a pre-commit script to back up
> the database to a disk file in the working copy. I would have a
> post-checkout script to reload the database from the disk file. Along with
> svn commit and svn checkout, this would give us the ability to roll back to
> any earlier version.
>
> What I can not imagine is how to get more than one person to be able to
> work on the site. Yes, Subversion would be able to merge changes to the disk
> files. But I don't see how Subversion can handle merging changes to the
> database. The MySQL database is text; perhaps someone here as experience
> with that. Can MySQL backup files be merged?
>
>

You'll need to analyze your app closely do it right, but it's absolutely
possible.

It's a daunting task for Drupal, WordPress, Joomla or any other CMS-driven
site and everyone who manages these type of sites deals with the issue
differently.

Subversion can handle whatever you svn commit. That's not the problem at
all. The filesystem files that make up your Drupal install are easy to
manage. You'll need to use svn:ignore on the uploads directory, cache, logs,
etc., but that's the easy part.

The tricky part is managing database schema under version control, and there
are myriad ways to output your db schema to a text file or files, try
phpMyAdmin for starters.

You have to plan your version control system to account for and
differentiate between dynamic/user-generated content in the database that it
needs to ignore, versus that which plays a critical role in the ui such as
dropdown items in forms.

You don't want your client's website content in your version control system
if you can avoid it, and with one well-written backup script you can achieve
it.

It goes without saying that you'll need at least one VM or additional
hosting account, virtual host on your server or other technique to develop
and/or stage your planned changes, too.

Apache Subversion 1.7.0-beta3 Released

[Hyrum Wright]

I'm happy to announce the release of Apache Subversion 1.7.0-beta3.
Please choose the mirror closest to you by visiting:

http://subversion.apache.org/download/#pre-releases

The SHA1 checksums are:

fdd22605c83ad601810e9cd980116ebcde45ef20 subversion-1.7.0-beta3.tar.gz
65c2d68522e3aac8870a81d942d9962bb5399ed3 subversion-1.7.0-beta3.tar.bz2
e4a9b4c97db74cb2931466a14311db10a6220039 subversion-1.7.0-beta3.zip

PGP Signatures are available at:

http://www.apache.org/dist/subversion/subversion-1.7.0-beta3.tar.bz2.asc
http://www.apache.org/dist/subversion/subversion-1.7.0-beta3.tar.gz.asc
http://www.apache.org/dist/subversion/subversion-1.7.0-beta3.zip.asc

For this release, the following people have provided PGP signatures:

   C. Michael Pilato [1024D/1706FD6E] with fingerprint:
20BF 14DC F02F 2730 7EA4  C7BB A241 06A9 1706 FD6E
   Paul T. Burba [1024D/53FCDC55] with fingerprint:
E630 CF54 792C F913 B13C  32C5 D916 8930 53FC DC55
   Julian Foad [1024D/353E25BC] with fingerprint:
6604 5A4B 43BC F994   5728 351F 33E4 353E 25BC
   Bert Huijben [1024D/9821F7B2] with fingerprint:
2017 F51A 2572 0E78 8827  5329 FCFD 6305 9821 F7B2
   Hyrum K. Wright [1024D/4E24517C] with fingerprint:
3324 80DA 0F8C A37D AEE6  D084 0B03 AE6E 4E24 517C
   Philip Martin [2048R/ED1A599C] with fingerprint:
A844 790F B574 3606 EE95  9207 76D7 88E1 ED1A 599C
   Stefan Sperling [1024D/F59D25F0] with fingerprint:
B1CF 1060 A1E9 34D1 9E86  D6D6 E5D3 0273 F59D 25F0
   Mark Phippard [1024D/035A96A9] with fingerprint:
D315 89DB E1C1 E9BA D218  39FD 265D F8A0 035A 96A9

This is a pre-release for what will eventually become Apache
Subversion 1.7.0.  There may still be minor issues, but all known
blocking issues have been fixed.

A pre-release means the Subversion developers feel that this release
is ready for widespread testing by the community.  Please use it at
your own risk, though we do encourage people to test this release
thoroughly.  Of particular note, please remember than persistent data,
such as the working copy or repository formats may change before the
final release, and there may not be an upgrade path from the
pre-releases to the final.

As a note to operating system distro packagers: while we wish to have this
release candidate widely tested, we do not feel that it is ready for packaging
and providing to end-users through a distro package system.  Packaging a
release candidate poses many problems, the biggest being that our policy lets
us break compatibility between the release candidate and the final release, if
we find something serious enough.  Having many users depending on a release
candidate through their distro would cause no end of pain and frustration that
we do not want to have to deal with.  However, if your distro has a branch that
is clearly labeled as containing experimental and often broken software, and
explicitly destined to consenting developers and integrators only, then we're
okay with packaging the release candidate there.  Just don't let it near the
end users please.


Release notes for the 1.7.x release series may be found at:

http://subversion.apache.org/docs/release-notes/1.7.html

You can find the list of changes between 1.7.0-beta3 and earlier versions at:

http://svn.apache.org/repos/asf/subversion/tags/1.7.0-beta3/CHANGES

Questions, comments, and bug reports to users@subversion.apache.org.

Thanks,
- The Subversion Team

Re: Subversion on Drupal

[Ryan Schmidt]

On Aug 11, 2011, at 21:56, Andy Canfield wrote:

> My goal in learning Subversion was to put our web site under version control. 
> Now I have my doubts as to whether Subversion can handle it.
> 
> The web site uses Drupal. And Drupal has the characteristic that much of the 
> site is contained in a MySQL database. For example, if I install a module and 
> set it up, the module is a disk file, but the configuration of that module is 
> in the database. If I make a change, part of the change may be in a PHP code 
> file on disk, part may be in the database. The database contains both user 
> data and configuration data, intermingled.
> 
> I could get Subversion to work. I would have a pre-commit script to back up 
> the database to a disk file in the working copy.

Not possible, because the working copy is on the client computer, whereas the 
pre-commit hook (and all hooks) run on the server computer. Unless you're 
saying you're working with a shared server-side working copy, in which case 
that's another thing I'd recommend not doing.


> I would have a post-checkout script to reload the database from the disk file.

There is no post-checkout hook, so this would have to be a script you run 
manually.

Re: Subversion on Drupal

[Andy Canfield]

On 08/12/2011 10:48 AM, Ryan Schmidt wrote:

On Aug 11, 2011, at 21:56, Andy Canfield wrote:


My goal in learning Subversion was to put our web site under version control. 
Now I have my doubts as to whether Subversion can handle it.

The web site uses Drupal. And Drupal has the characteristic that much of the 
site is contained in a MySQL database. For example, if I install a module and 
set it up, the module is a disk file, but the configuration of that module is 
in the database. If I make a change, part of the change may be in a PHP code 
file on disk, part may be in the database. The database contains both user data 
and configuration data, intermingled.

I could get Subversion to work. I would have a pre-commit script to back up the 
database to a disk file in the working copy.

Not possible, because the working copy is on the client computer, whereas the 
pre-commit hook (and all hooks) run on the server computer. Unless you're 
saying you're working with a shared server-side working copy, in which case 
that's another thing I'd recommend not doing.
My poor expression. It's not on a hook. I mean that when Charlie wants 
to do a checkout, Charlie must do this:

[1] svn checkout ...
[2] cd repository
[3] scripts/post-checkout.sh
My workstation shell script, which is stored in the same repository, 
takes care of reloading the database. I think that the script will work 
for both Linux and OS X; forget Windows.



I would have a post-checkout script to reload the database from the disk file.

There is no post-checkout hook, so this would have to be a script you run 
manually.


Similarly, when Charlie wants to commit, Charlie must do this:
[1] in GUI, do a Drupal manual backup (maybe I can trigger this in 
a script)

[1] cd repository
[2] scripts/pre-commit.sh
[3] svn commit ...

The pre-commit and post-checkout scripts try to take care of putting the 
database into the revision. They also take care of the problem that some 
files in some directories are created by, and therefore owned by, the 
Apache "user" and must be writable by the Apache "user" in any working 
copy. Subversion stores permissions but does not store ownership;  a 
file owned by user "www-data" under Linux must be writable by user 
"_www" on OS X. And, of course, the scripts would have to fix any other 
problems I run into. Also I might need an "UPDATE" script.