Re: Sync SVN to CVS
Guten Tag SUMNER Andrew, am Mittwoch, 30. März 2011 um 20:42 schrieben Sie: > Our operations group require that the database scripts are in cvs, > however the developers are using svn for everything else and it > would prefer to be using the one tool. And of course it's no option to switch operations group to SVN, right? Seems you need to write your own tool/script. Depending on the amount of files, directory structure etc. it may not be too much effort. You need two working copys, that one for SVN, the one for CVS, update the SVN working copy regularly, copy files, commit to CVS with the logs used form the SVN revisions. 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: Sync SVN to CVS
I believe the freebsd folks do some mirroring svn->cvs: http://svn.freebsd.org/ http://svn.freebsd.org/viewvc/base/svnadmin/tools/export.py?view=markup http://svn.freebsd.org/base/ROADMAP.txt Thorsten Schöning wrote on Thu, Mar 31, 2011 at 09:11:15 +0200: > Guten Tag SUMNER Andrew, > am Mittwoch, 30. März 2011 um 20:42 schrieben Sie: > > > Our operations group require that the database scripts are in cvs, > > however the developers are using svn for everything else and it > > would prefer to be using the one tool. > > And of course it's no option to switch operations group to SVN, right? > Seems you need to write your own tool/script. Depending on the amount > of files, directory structure etc. it may not be too much effort. You > need two working copys, that one for SVN, the one for CVS, update the > SVN working copy regularly, copy files, commit to CVS with the logs > used form the SVN revisions. > > 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: Sync SVN to CVS
If all they do is "update" to the trunk's latest revision, it could be done taking checking out the SVN source and committing it into SVN. Care should be taken with added/deleted files; I think there was an easy way using ¿external branches? (like 1.0.1.1). If you need releases / tags, it only gets a bit more difficult as long as you use releases as tags (i.e., only the copy from trunk, and no more commits). On Wed, Mar 30, 2011 at 19:42, SUMNER Andrew wrote: > Our operations group require that the database scripts are in cvs, however > the developers are using svn for everything else and it would prefer to be > using the one tool. > > My eventual goal being continuous deployment into test using Jenkins (also > would love to hear from anyone who has done this for database changes...) > > Andrew > > -Original Message- > From: Thorsten Schöning [mailto:tschoen...@am-soft.de] > Sent: Wednesday, 30 March 2011 20:34 > To: users@subversion.apache.org > Subject: Re: Sync SVN to CVS > > Guten Tag SUMNER Andrew, > am Dienstag, 29. März 2011 um 21:56 schrieben Sie: > > > 1. Are there any tools to sync SVN to CVS? Ideally I would like > > two way sync but I may be able to get away with one way (svn -> cvs) > > especially if it can throw an error if the cvs file has changed. > [...] > > The repository I wish to sync contains database script files. > > And what's the purpose you need the sync for or what problem do you > need to solve? It's unlikely that you find a tool which syncs as you > need, but maybe one has another idea on how to solve your problem. > > 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 > > The information contained in this e-mail may be privileged and/or > sensitive. It is intended for the addressee only and is not necessarily the > official view or communication of the New Zealand Customs Service. If you > are not the intended recipient you are asked to not disclose, copy, or make > use of its contents. If received in error you are asked to destroy this > e-mail and contact the sender immediately. Your assistance is appreciated. >
Re: subversion authz wildcard
On Wed, Mar 30, 2011 at 09:43:27PM -0700, Michael Mac (Palm GBU) wrote: > Hi, > > I'd to query the user community to know if there's been any progress > in using wildcards with authz? Is there a work around for this? There > was previous mentioned that version 1.7 may have this feature > enhancement, but not a guarantee. See http://subversion.tigris.org/issues/show_bug.cgi?id=2662 You can add yourself to the Cc list there to get progress information via email. I took a look at one of the patch submissions we've received for this. Unfortunately, it didn't qualify, see http://subversion.tigris.org/issues/show_bug.cgi?id=2662#desc20 If we decide to disallow leading wildcard characters, though, that patch would work. There is another patch submission, against an old version of Subversion. The approach it is taking seems to be workable. However, applying this patch on top of trunk is a huge chunk of work. We'll also need to find out whether it's actually usable in practice, since it needs to crawl a lot of paths in a repository in case of wildcards such as */tags (as explained in the issue). So while it might work, performance might turn out to be dismal for large repositories. > On related topic others have > mentioned that svnperms.py can support wildcard. I have confirmed > svnperms.py can support wildcard, > It only seems to support trailing wildcards (i.e. /trunk/* but not */tags). > but my problem is svnperms.py is it > only accept single word username. My company is using both first name > and last name for the user login name with a white space between them. > i.e "firstname lastname". Svnperms.py doesn't seem to be able to > support this structure. Does anyone know how I can modify svnperms.py > to accept white space in user login name? Does this patch help (untested)? It should group usernames containing whitespace properly, provided you use quoting in svnperms.conf: [groups] group1 = "Arthur Dent" Marvin 'Ford Prefect' Index: tools/hook-scripts/svnperms.py === --- tools/hook-scripts/svnperms.py (revision 1086745) +++ tools/hook-scripts/svnperms.py (working copy) @@ -28,6 +28,8 @@ import sys, os import getopt +import shlex + try: # Python >=3.0 from subprocess import getstatusoutput as subprocess_getstatusoutput @@ -129,7 +131,7 @@ class Permission: def parse_groups(self, groupsiter): for option, value in groupsiter: groupusers = [] -for token in value.split(): +for token in shlex.split(value): # expand nested groups in place; no forward decls if token[0] == "@": try:
Re: minimalist example of svn_txdelta_run?
On Thu, Mar 31, 2011 at 12:02 AM, Daniel Shahaf wrote: > Typically to update a file in the repository using the svn_delta API > you'd already know the current contents of that file. Is that the case > for you? > > What are you trying to do? Can you give an example with sample data? Well, what I was trying to do in my test case was take a file in a repository with content "test string 1", and update its content to "test string 2" using mechanisms that would confirm there is a difference between those two strings before updating the file to the new string - basically the simplest possible situation. The "real" problem I'm trying to solve is this - I have binary data stored in lots of small files in a subversion repository (serialized geometry data). I have as incoming data the serialized binary data for one of the objects. I want to commit the new contents from the incoming object to the repository, if that incoming data is different from the version that is already in the repository. All of this is in-memory, no filesystem files are involved except what the FSFS backend is doing internally. Cheers, CY
Clearvision Survey: Open Source – The Unknown
Two things you did not know about open source software . . . . 1) It can SAVE your company money. 2) It can COST your company its reputation. Does your company have a safeguard or policy for monitoring its source code? You may not know that it only takes a small amount of unlicensed code within your software program to raise a lawsuit. Please take thirty seconds to fill out our short survey on open source awareness. http://www.surveymonkey.com/s/J7SMVLV
Using tags with SVN
Hello, I'm currently thinking about migrating from CVS to SVN, since SVN is said to be the successor of CVS. When analyzing the differences between CVS and SVN I found tags are treated in a different way in SVN, than they were treated in CVS, because the tag concept in SVN is: A tag is just a "snapshot" of a project in time. This differs somewhat from the CVS concept of a tag: "You can use the tag command to give a symbolic name to a certain revision of a file." We use tags in CVS to identify the files which have passed module tests and should make it into our integration test environment. When they have passed the integration tests we use a different tag to identify the files, which make up the software in/for our production environment. In addition to that our development model is not release driven. As a result we do not tag the HEAD of our complete source tree at a particular point in time. As soon as we have finished development of a feature or functionality we tag the files which have been changed with a tag named "Q". In a different workspace we check out the "Q" tagged source tree. This gives us the possibility to go on developing a feature while doing the integration test on a previous revision of it and have a source tree which consists of files, which reached the state of being ready for integration tests or for production at different points in time. In my opinion branches would be too complicated to achieve the same functionality. Does anyone have an idea how to achieve this flexibility and ease of use with branches in SVN? Thanks, Siggi
Re: minimalist example of svn_txdelta_run?
Clifford Yapp wrote on Thu, Mar 31, 2011 at 08:50:37 -0400: > On Thu, Mar 31, 2011 at 12:02 AM, Daniel Shahaf > wrote: > > > Typically to update a file in the repository using the svn_delta API > > you'd already know the current contents of that file. Is that the case > > for you? > > > > What are you trying to do? Can you give an example with sample data? > > Well, what I was trying to do in my test case was take a file in a > repository with content "test string 1", and update its content to > "test string 2" using mechanisms that would confirm there is a > difference between those two strings before updating the file to the > new string - basically the simplest possible situation. > Okay, that sounds right. (Depending on your scenario, I guess you might be able to skip the check and go directly to attempting the commit.) I'll reply to your other mail in a second. > The "real" problem I'm trying to solve is this - I have binary data > stored in lots of small files in a subversion repository (serialized > geometry data). I have as incoming data the serialized binary data > for one of the objects. I want to commit the new contents from the > incoming object to the repository, if that incoming data is different > from the version that is already in the repository. All of this is > in-memory, no filesystem files are involved except what the FSFS > backend is doing internally. > > Cheers, > CY
Re: minimalist example of svn_txdelta_run?
Clifford Yapp wrote on Wed, Mar 30, 2011 at 19:46:04 -0400:
> 2) is there an example somewhere of this process being done in C code
> as a minimal example? Something along the lines of "given a
> repository and two strings str1 and str2, here's how to apply the
> difference to a file in a repository?"
>
> A code snippet appears below to better illustrate what I'm trying to
> do - I can expand it if that would help any.
>
> Thanks,
> CY
>
> svn_repos_get_commit_editor4(editor, &edit_baton, repos, NULL,
> full_path, base, user, logmsg, NULL, NULL, NULL, NULL, pool);
> (*editor)->open_root(edit_baton, youngest_rev, pool, &root_baton);
> (*editor)->open_file(bu_vls_addr(&filepath), root_baton,
> youngest_rev, pool, &file_baton);
> char *testcontents = "test contents 2";
> teststring = svn_string_createf(pool, "%s", testcontents2);
> svn_stream_t *newstream = svn_stream_from_string(teststring, pool);
> (*editor)->apply_textdelta(file_baton, NULL, pool, &handler, &handler_baton);
> svn_txdelta_run(oldstream, newstream, handler, handler_baton,
> svn_checksum_md5, &local_checksum, NULL, NULL, pool, pool);
> (*editor)->close_file(file_baton, NULL, pool);
> (*editor)->close_edit(edit_baton, pool);
The first thing to say is that you aren't checking the error return
values. Try compiling with -DSVN_DEBUG --- that will cause an abort()
if you missed an error return.
That's all that jumps out at me right now :(. If I had to learn this API
I'd do so by writing a dummy C test --- eg in
subversion/tests/libsvn_{fs,delta}/ ---
which is also where you might be able to find a 'minimal example'.
Re: minimalist example of svn_txdelta_run?
On Thu, Mar 31, 2011 at 1:45 PM, Daniel Shahaf wrote:
> The first thing to say is that you aren't checking the error return
> values. Try compiling with -DSVN_DEBUG --- that will cause an abort()
> if you missed an error return.
I know - this is in the "quick and dirty" category, so I'll have to go
back later and deal with that.
> That's all that jumps out at me right now :(. If I had to learn this API
> I'd do so by writing a dummy C test --- eg in
> subversion/tests/libsvn_{fs,delta}/ ---
> which is also where you might be able to find a 'minimal example'.
Ah, thanks! I hadn't thought of the tests dir - I'm building a subset
of subversion with CMake, so I missed those.
I managed to get the changed I need into the files with a full on copy
of the contents, which is somewhat suboptimal but workable for small
files.
Cheers, and thanks again.
CY
RE: Using tags with SVN
> I'm currently thinking about migrating from CVS to SVN, since SVN > is said to be the successor of CVS. > When analyzing the differences between CVS and SVN I found tags are > treated in a different way in SVN, than they were treated in CVS, > because the tag concept in SVN is: A tag is just a "snapshot" of a > project in time. > This differs somewhat from the CVS concept of a tag: "You can use > the tag command to give a symbolic name to a certain revision of a > file." > We use tags in CVS to identify the files which have passed module > tests and should make it into our integration test environment. So you are saying you test "files" in isolation? That seems a bit unusual I think. In svn you use a "tag" to give a symbolic name to a certain revision also. It's really not all that different. > When they have passed the integration tests we use a different tag > to identify the files, which make up the software in/for our > production environment. In addition to that our development model > is not release driven. As a result we do not tag the HEAD of our > complete source tree at a particular point in time. As soon as we > have finished development of a feature or functionality we tag the > files which have been changed with a tag named "Q". In a different > workspace we check out the "Q" tagged source tree. This gives us > the possibility to go on developing a feature while doing the > integration test on a previous revision of it and have a source > tree which consists of files, which reached the state of being > ready for integration tests or for production at different points > in time. In my opinion branches would be too complicated to achieve > the same functionality. > Does anyone have an idea how to achieve this flexibility and ease > of use with branches in SVN? What you described above is exactly what branches are for. Why do you think this would be complicated? This is exactly the description of a branch for release use case. I think you are over thinking this... how is tagging a revision that contains the changes for a feature with a "Q" than tagging each file with a "Q"? BOb
RE: Advice on upgrading svn and moving to new server
> > On Wed, Mar 30, 2011 at 3:17 PM, Daniel Shahaf > wrote: > > Kevin Grover wrote on Wed, Mar 30, 2011 at 08:13:34 -0700: > >> When upgrading, mostly you can still access old repositories. > SOMETIMES > >> they will be silently upgraded in someways > > > > I don't know that the above sentence is correct. Can you give > > an example of a scenario when that happens? > > Working copies will be upgraded silently. A working copy is not a repository though. BOb
Re: Using tags with SVN
On Thu, Mar 31, 2011 at 12:31 PM, Stirnweiss, Siegmund SZ/HZA-ZIT3 wrote: > Hello, > > I’m currently thinking about migrating from CVS to SVN, since SVN is said to > be the successor of CVS. > > When analyzing the differences between CVS and SVN I found tags are treated > in a different way in SVN, than they were treated in CVS, because the tag > concept in SVN is: A tag is just a “snapshot” of a project in time. Tags are suppose to be "snapshots" of a particular version of the application. Sometimes you can adjust a tag if you've tagged the wrong file, but that should be fairly rare. In Subversion, tags take less than a second to do while in CVS, you have to tag each and every file. Long files have to be rewritten after every tag. That, to me is a great advantage in Subversion. > We use tags in CVS to identify the files which have passed module tests and > should make it into our integration test environment. When they have passed > the integration tests we use a different tag to identify the files, which > make up the software in/for our production environment. In addition to that > our development model is not release driven. As a result we do not tag the > HEAD of our complete source tree at a particular point in time. Whoa! That's dangerous. When you pick and choose tags, you may end up tagging the wrong file. Then, this is a CM error and not a developer error. That means the Finger o' Blame points to you and not to the developer who gave you the wrong file or forgot a file. You want that Finger o' Blame pointing not at you. I just came to my current position a couple of months ago, and that's exactly what we were doing. Tagging particular files, and then attempting to build from that tag. I put an immediate stop to that. We build on the head of the branches now. That has eliminated about half of our build errors and deployments go much smoother. Now, there's nothing in Subversion preventing you from attaching a tag to a particular version of a file. You simply copy files to the tag directory one at a time. When a file gets approved, you "tag" it. It's not the standard way to do it, but I've seen shops that do. Even better, Subversion tracks when things were tagged and branched. In CVS, you have no idea when a tag or a branch was created and applied. -- David Weintraub qazw...@gmail.com
