Re: Tagging svn:externals
> From: Les Mikesell > To: Bob Archer > Cc: C M ; "users@subversion.apache.org" > > Sent: Wednesday, February 20, 2013 1:03 PM > Subject: Re: Tagging svn:externals > > On Wed, Feb 20, 2013 at 11:52 AM, Bob Archer wrote: >> Some clients like TortoiseSVN have a feature that will pin the external to >> the revision you are copping when doing the tag. Otherwise, you have to do >> it manually before or after you create your tag. > > Neither choice 'feels' quite right to me unless you have an > intermediate branch to make the change. That is, if you make it on > the trunk before you copy to the tag you break the likely continuing > work on the trunk that expects the externals to also follow trunk > components. And if you change it in the tag you are breaking the > convention that you don't change tags. And if you copy the working > copy to a tag you might get other changes in the tag that weren't > committed anywhere else. Is there a 'best practice' consensus for > this step? > While I do agree, I think the simple solution is to generally just use tagged externals to start with, and then switch them to trunk or a branch when you need to work on them from that project. Not only does it solve the above, but it also enforces a discipline in how projects are updated to use newer versions of the tags; it also requires developers to be aware of which externals affect which projects - which, IMHO, is a good thing. $0.02 Ben
Re: Tagging svn:externals
On Thu, Feb 21, 2013 at 9:42 AM, BRM wrote: > >> On Wed, Feb 20, 2013 at 11:52 AM, Bob Archer wrote: >>> Some clients like TortoiseSVN have a feature that will pin the external to >>> the revision you are copping when doing the tag. Otherwise, you have to do >>> it manually before or after you create your tag. >> >> Neither choice 'feels' quite right to me unless you have an >> intermediate branch to make the change. That is, if you make it on >> the trunk before you copy to the tag you break the likely continuing >> work on the trunk that expects the externals to also follow trunk >> components. And if you change it in the tag you are breaking the >> convention that you don't change tags. And if you copy the working >> copy to a tag you might get other changes in the tag that weren't >> committed anywhere else.Is there a 'best practice' consensus for >> this step? >> > > While I do agree, I think the simple solution is to generally just use tagged > externals to start with, and then switch them to trunk or a branch when you > need to work on them from that project. That makes sense when you aren't concurrently working on a component and the project using it. But that is the problem case - and common. > Not only does it solve the above, but it also enforces a discipline in how > projects are updated to use newer versions of the tags; it also requires > developers to be aware of which externals affect which projects - which, > IMHO, is a good thing. Sure, it would be great if every component had well-tested, frozen APIs at release quality before any upper level project touched them. But on the other hand, APIs tend to miss the mark if they aren't adjusted for the needs of real-world use. So there's a problem either way -- Les Mikesell lesmikes...@gmail.com
is that possible the same code under two different subversion service provider?
Hi: Suppose our project tree look like: project/aaa project/bbb Currrently, the whole project tree is under subversion control provided by company A. In the same time, I also want to put the sub directory project/aaa under subversion control provided by company B. The reason for doing that is somebody abroad is cooperating with us and his work is in project/aaa. He does not have the access to the company A's repo. He can access company B's repo. So is there a way to let project/aaa under two different subversion? When he changes the code inside project/aaa, he checks in to company B's central repository, I pull out his change from company B to my local area. Then I check in his code change into company A's repo on behalf of him. Is this doable? Thank you.
Re: Tagging svn:externals
Les Mikesell writes: > Neither choice 'feels' quite right to me unless you have an > intermediate branch to make the change. That is, if you make it on > the trunk before you copy to the tag you break the likely continuing > work on the trunk that expects the externals to also follow trunk > components. And if you change it in the tag you are breaking the > convention that you don't change tags. And if you copy the working > copy to a tag you might get other changes in the tag that weren't > committed anywhere else.Is there a 'best practice' consensus for > this step? You could write a script using svnmucc so that the copy and the property change happen in the same commit. We do something like that when tagging Subversion, we edit a header when we make a tag: $ svn log -vq --stop-on-copy http://svn.apache.org/repos/asf/subversion/tags/1.7.8 r1419826 | breser | 2012-12-10 22:01:28 + (Mon, 10 Dec 2012) Changed paths: A /subversion/tags/1.7.8 (from /subversion/branches/1.7.x:1419691) M /subversion/tags/1.7.8/subversion/include/svn_version.h -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: is that possible the same code under two different subversion service provider?
Guten Tag frame, am Donnerstag, 21. Februar 2013 um 17:19 schrieben Sie: > Suppose our project tree look like: > project/aaa > project/bbb > Currrently, the whole project tree is under subversion control > provided by company A. In the same time, I also want to put the sub > directory project/aaa under subversion control provided by company > B. The reason for doing that is somebody abroad is cooperating with > us and his work is in project/aaa. He does not have the access to > the company A's repo. He can access company B's repo. So is there a > way to let project/aaa under two different subversion? When he > changes the code inside project/aaa, he checks in to company B's > central repository, I pull out his change from company B to my local > area. Then I check in his code change into company A's repo on behalf of him. > Is this doable? Sounds like a vendor branch to me, where the source of the branch was a dumped part of your repo, imported into the other. But afterwards everything else should fit vendor branch best practice. http://svnbook.red-bean.com/en/1.7/svn.advanced.vendorbr.html Just as an idea: Did you have a look at things like git2svn etc.? Your cooperator with access to company B could simply work on it's own repo, implemented with git or whatever, and you could import the changes he made into your repo like a vendor branch again, just using git2svn or else. Id don't think its necessary that your cooperator commits into another subversion repo. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: is that possible the same code under two different subversion service provider?
On 02/21/2013 01:15 PM, Thorsten Schöning wrote: > Guten Tag frame, > am Donnerstag, 21. Februar 2013 um 17:19 schrieben Sie: > >> Suppose our project tree look like: > >> project/aaa >> project/bbb > >> Currrently, the whole project tree is under subversion control >> provided by company A. In the same time, I also want to put the sub >> directory project/aaa under subversion control provided by company >> B. The reason for doing that is somebody abroad is cooperating with >> us and his work is in project/aaa. He does not have the access to >> the company A's repo. He can access company B's repo. So is there a >> way to let project/aaa under two different subversion? When he >> changes the code inside project/aaa, he checks in to company B's >> central repository, I pull out his change from company B to my local >> area. Then I check in his code change into company A's repo on behalf of >> him. Is this doable? > > Sounds like a vendor branch to me, where the source of the branch was > a dumped part of your repo, imported into the other. But afterwards > everything else should fit vendor branch best practice. > > http://svnbook.red-bean.com/en/1.7/svn.advanced.vendorbr.html I was thinking the same thing, though I wouldn't bother with the dump/load initializing step -- a history-free export/import should be sufficient. Note that I recently rewrote that section of the book a bit (I never really liked what I'd come up with in earlier book versions). You can see the nightly build version of that information at: http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html (Feedback about the book should go to svnbook-...@red-bean.com, though, not to this list.) -- C. Michael Pilato CollabNet <> www.collab.net <> Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: Tagging svn:externals
On Feb 21, 2013, at 11:18, Philip Martin wrote: > Les Mikesell writes: > >> Neither choice 'feels' quite right to me unless you have an >> intermediate branch to make the change. That is, if you make it on >> the trunk before you copy to the tag you break the likely continuing >> work on the trunk that expects the externals to also follow trunk >> components. And if you change it in the tag you are breaking the >> convention that you don't change tags. And if you copy the working >> copy to a tag you might get other changes in the tag that weren't >> committed anywhere else.Is there a 'best practice' consensus for >> this step? > > You could write a script using svnmucc so that the copy and the property > change happen in the same commit. We do something like that when > tagging Subversion, we edit a header when we make a tag: I thought that's what the svncopy.pl script is supposed to do. http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svncopy/svncopy.README
antivirus messing up a checkout
I'm trying to checkout a public repo on a windows box, and a corporate antivirus is screwing me by flagging a .svn file as a virus and deleting it (thus rendering the checkout invalid). svn co -q http://www.boxbackup.org/svn/box/RELEASE/0.11.1 The "bad" file is .svn/pristine/bd/bd10f1e696452058fbb0bbe2eff52c03437cb033.svn-base 'file' reports it as: ..svn/pristine/bd/bd10f1e696452058fbb0bbe2eff52c03437cb033.svn-base: PE32 executable for MS Windows (GUI) Intel 80386 32-bit So it looks like a windows exe which gets the antivirus program (McAfee Enterprise) all hot and bothered flagging the file as Artemis!7F2A64279A7D and deleting it. Of course, I can't disable the AV for that file on this $corp windows box (group policy doesn't allow that). Workarounds? I thought about converting to a different version control program (convert svn to mercurial on checkout for instance), but I'm not sure that would work and I wanted to keep it as a svn repo if possible.
Re: antivirus messing up a checkout
On Feb 21, 2013, at 21:28, hfpwzq3...@snkmail.com wrote: > I'm trying to checkout a public repo on a windows box, and a corporate > antivirus is screwing me by flagging a .svn file as a virus and deleting it > (thus rendering the checkout invalid). > > svn co -q http://www.boxbackup.org/svn/box/RELEASE/0.11.1 > > The "bad" file is > .svn/pristine/bd/bd10f1e696452058fbb0bbe2eff52c03437cb033.svn-base That file is http://www.boxbackup.org/svn/box/RELEASE/0.11.1/contrib/windows/installer/tools/RemoteControl.exe No idea what it is, but with a name like that, I can see why some $corps might be wary of it. A number of AV programs detect it as malware, not just McAfee: https://www.virustotal.com/en/file/f397be215ab82732e6d3ed29905f62b03b49c2d2d4d6f8852f350ca2da619435/analysis/ As for how to work around the problem, I guess you can avoid checking out that file by doing svn co --depth immediates http://www.boxbackup.org/svn/box/RELEASE/0.11.1 to get one level of files/directories in the 0.11.1 directory, cd into 0.11.1, then do svn up --set-depth infinity on all directories besides contrib. Then depending on what (if anything) you want from the contrib directory, cd in there and svn up --set-depth immediates, etc… getting as much as you can, while avoiding /contrib/windows/installer/tools/RemoteControl.exe Perhaps there's an easier way to do this; I've never tried to exclude a specific file from a checkout. -- Name: Dave Huang | Mammal, mammal / their names are called / INet: k...@azeotrope.org | they raise a paw / the bat, the cat / FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG Dahan: Hani G Y+C 37 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
