Re: Sub-Version Query
Hi, I am trying to download SVN server binary files fromnbsp; http://subversion.apache.org/packages.html#redhat to installnbsp; on RedHat linux 5 but binary that gets downloaded is just 5 KB (I cliecked on WANdisco link to download). Kindly let me know - 1. If this is the right place to download free SVN server binary file? 2.Is there any step by step installation guide for SVN server and smartsvn client ? Regards, AnupamFrom: Phil Pinkerton lt;pcpinker...@gmail.comgt;Sent: Wed, 08 May 2013 19:31:07 To: Anupam Choubey lt;helloanu...@rediffmail.comgt;Cc: users@subversion.apache.org lt;users@subversion.apache.orggt;Subject: Re: Sub-Version QueryYou answers are here:nbsp;http://subversion.apache.org On May 8, 2013, at 3:30 AM, Anupam nbsp;Choubey lt;helloanu...@rediffmail.comgt; wrote: Hi, I have some queries on subversion - 1. What is the latest version avaiable of subversion? 2. What is the harrdware amp; software infrastructure required to install the subversion? 3. Is subversion a freeware or licensed sowtware? 4.I have to move some code base with all the versions of file nbsp;from CVS to subversion . Isnbsp;it doable? if yes how? Thanks in advance for your help. Regards, Anupamnbsp; Get your own FREE website and domain with business email solutions, click here
Re: Sub-Version Query
Guten Tag Anupam Choubey, am Freitag, 10. Mai 2013 um 08:16 schrieben Sie: I am trying to download SVN server binary files from http://subversion.apache.org/packages.html#redhat to install on RedHat linux 5 but binary that gets downloaded is just 5 KB (I cliecked on WANdisco link to download). Please don't answer on old questions which completely new topics, this makes it unnecessary confusing to follow you. Said that, the provided binary is just an installer and may be this small, just follow the instructions on the right next to the download. 1. If this is the right place to download free SVN server binary file? It's one of many, yes. 2.Is there any step by step installation guide for SVN server and smartsvn client ? You could start following the docs and may ask for any problems you run into: http://svnbook.red-bean.com/en/1.7/svn.reposadmin.html 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: Server sent unexpected return value (403 Forbidden) in response to PROPFIND
Perfect :d, as you said i've removed .subversion/auth content and re-run the same command and it worked Thank you so much for your help ;) Regards Mehdi
Re: Server sent unexpected return value (403 Forbidden) in response to PROPFIND
You're welcome. Glad I could help. :) Thanks, Katherine — Sent from Mailbox for iPhone On Fri, May 10, 2013 at 9:05 AM, Mehdi Hayani hayani.mehdi...@gmail.com wrote: Perfect :d, as you said i've removed .subversion/auth content and re-run the same command and it worked Thank you so much for your help ;) Regards Mehdi
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
-Original Message- From: Branko Čibej [mailto:br...@wandisco.com] Sent: Thursday, May 09, 2013 4:35 PM To: users@subversion.apache.org Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects? Well, given that you have not created any branches, this works as expected :) There are no branch points in your repository; only directories. A branch is created by copying a directory (with svn copy), not by creating it (with svn mkdir), and that is why your -- stop-on-copy works the way it does -- the only copy is a side effect of the rename (which is currently represented as copy+delete), hence -- stop-on-copy stops ... when it sees the copy. No, the effect is the same whether you use 'svn mkdir', 'svn copy', or 'svn mv', for single dirs or for trees full of files and subdirs. If you change the name or path of a parent dir, you implicitly create a common revision across each and every subdir and file. If you svn mv ^/tag ^/tags or svn mv ^/branches ^/project1/branches then everything under /tags or /project1/branches will now have a new, common, revision according to 'svn log'. It's not a huge problem, but in the real world (i.e. a non-contrived example) I have branches that have been locked and untouched for months that now have a new HEAD revision. And those branches, which are supposed to be walled off from each other until explicitly merged, now have a revision in common. (*Every* file and dir in the branches and tags dir trees now has the new, shared rev.) I can understand why it happens; svn log needs to know about the parent dir rename in order to know (and print) the correct paths for subsequent revisions. It's a mostly harmless side effect of copy/mv, but it is odd looking and seems sloppy from a purist point of view because something outside of the branch is changing the branch's history and baseline albeit in a mostly limited fashion. Anyway, if you never restructure your high-level tags/branches/trunk dir structure and if you never rename a branch or tag, then you won't see this problem. The real problem here is that Subversion does not treat /renames/ as atomic operations. This is indeed being addressed, but a complete solution will take time. I'm not going to go into technical details here; if you're interested, you're welcome to join the dev@ list and listen in (or participate) in the discussions there. Yeah, I'm aware of the rename issue (I have a background in ClearCase,) but the 'lack of branches' is a whole issue in and of itself. A branch really should be a walled off garden until you explicitly merge.
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Fri, May 10, 2013 at 09:40:48AM -0400, Andrew Reedick wrote: It's not a huge problem, but in the real world (i.e. a non-contrived example) I have branches that have been locked and untouched for months that now have a new HEAD revision. And those branches, which are supposed to be walled off from each other until explicitly merged, now have a revision in common. (*Every* file and dir in the branches and tags dir trees now has the new, shared rev.) It is strange behaviour on a conceptual level if you are used to thinking in terms of other version control systems (such as ClearCase in your case). However, it is a natural consequence of the way Subversion is currently supposed to represent the concepts of versioning files and directories, and labels and branches. And it has done so for over a decade. Changing this behaviour is far from trivial. I'm not entirely sure what kind of answer you are hoping to get. Are you happy with the answer that Subversion is simply not ClearCase?
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 10.05.2013 15:56, Stefan Sperling wrote: On Fri, May 10, 2013 at 09:40:48AM -0400, Andrew Reedick wrote: It's not a huge problem, but in the real world (i.e. a non-contrived example) I have branches that have been locked and untouched for months that now have a new HEAD revision. And those branches, which are supposed to be walled off from each other until explicitly merged, now have a revision in common. (*Every* file and dir in the branches and tags dir trees now has the new, shared rev.) It is strange behaviour on a conceptual level if you are used to thinking in terms of other version control systems (such as ClearCase in your case). However, it is a natural consequence of the way Subversion is currently supposed to represent the concepts of versioning files and directories, and labels and branches. And it has done so for over a decade. Changing this behaviour is far from trivial. I'm not entirely sure what kind of answer you are hoping to get. Are you happy with the answer that Subversion is simply not ClearCase? I can understand that having the Revision in svn info output change on what you expect is a conceptually read-only branch can be confusing. It's also unfortunate that the sort of refactoring mentioned (moving the branch root directory, for example) will disappoint users who expect to use --stop-on-copy for branch point detection. Proper rename tracking should, at least, avoid that issue. Having first-class branches would be nice (I've often said so), but they'd probably have to be implemented as an extension orthogonal to the current versioned-tree model. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Fri, May 10, 2013 at 8:40 AM, Andrew Reedick andrew.reed...@cbeyond.net wrote: It's not a huge problem, but in the real world (i.e. a non-contrived example) I have branches that have been locked and untouched for months that now have a new HEAD revision. And those branches, which are supposed to be walled off from each other until explicitly merged, now have a revision in common. (*Every* file and dir in the branches and tags dir trees now has the new, shared rev.) I can understand why it happens; svn log needs to know about the parent dir rename in order to know (and print) the correct paths for subsequent revisions. It's a mostly harmless side effect of copy/mv, but it is odd looking and seems sloppy from a purist point of view because something outside of the branch is changing the branch's history and baseline albeit in a mostly limited fashion. Isn't this just a difference in subversion's and your thinking about the significance of the path change? Subversion is going to see the path change affecting everything below it because of the way it holds projects together. Is there some reason you are changing a common parent path and thinking that it should not affect everything below? Is it 'above' what you think of as the actual project? -- Les Mikesell lesmikes...@gmail.com
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
-Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Friday, May 10, 2013 9:57 AM To: Andrew Reedick Cc: Branko Čibej; users@subversion.apache.org Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects? On Fri, May 10, 2013 at 09:40:48AM -0400, Andrew Reedick wrote: It's not a huge problem, but in the real world (i.e. a non-contrived example) I have branches that have been locked and untouched for months that now have a new HEAD revision. And those branches, which are supposed to be walled off from each other until explicitly merged, now have a revision in common. (*Every* file and dir in the branches and tags dir trees now has the new, shared rev.) It is strange behaviour on a conceptual level if you are used to thinking in terms of other version control systems (such as ClearCase in your case). However, it is a natural consequence of the way Subversion is currently supposed to represent the concepts of versioning files and directories, and labels and branches. And it has done so for over a decade. Changing this behaviour is far from trivial. I'm not entirely sure what kind of answer you are hoping to get. Are you happy with the answer that Subversion is simply not ClearCase? I've been using svn since 1.3, so I'm aware of the design limitations. And yes, I would recommend svn over clearcase in most situations. Anyway, the whole exercise started when I needed a report script to find the common ancestor between two branches and ran into the 'parent dir change false revision' issue. Then I started going through potential edge cases and realized just how fragile svn branches were (where fragile == dependent on human processes and conventions.) Which in turn made me realize just how basic (i.e. bare metal) svn is in regards to meta-features such as branching, tagging, baselines, workflows, etc.. It makes me wonder if it would make sense to slap a higher-level interface on top of svn in order to implement the process aspects of version control (and otherwise hide/keep the lower level details/quirks away from users.)
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Fri, May 10, 2013 at 10:20:54AM -0500, Andrew Reedick wrote: It makes me wonder if it would make sense to slap a higher-level interface on top of svn in order to implement the process aspects of version control (and otherwise hide/keep the lower level details/quirks away from users.) Yes, that makes sense. Subversion doesn't know anything about process. It only cares about version control. Process aspects are left to higher-level tools. For example, Subversion is often tied to an issue tracker, with a pre-commit hook that requires an issue number in the log message and then checks the status if the issue to decide whether the commit should be allowed according to policy. Or people use hook scripts such as this one: http://svn.haxx.se/dev/archive-2012-04/0392.shtml http://svn.haxx.se/dev/archive-2012-04/0394.shtml I've also seen custom Subversion clients written to support a particular process.
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
-Original Message- From: Les Mikesell [mailto:lesmikes...@gmail.com] Sent: Friday, May 10, 2013 11:00 AM To: Andrew Reedick Cc: Branko Čibej; users@subversion.apache.org Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects? On Fri, May 10, 2013 at 8:40 AM, Andrew Reedick andrew.reed...@cbeyond.net wrote: It's not a huge problem, but in the real world (i.e. a non-contrived example) I have branches that have been locked and untouched for months that now have a new HEAD revision. And those branches, which are supposed to be walled off from each other until explicitly merged, now have a revision in common. (*Every* file and dir in the branches and tags dir trees now has the new, shared rev.) I can understand why it happens; svn log needs to know about the parent dir rename in order to know (and print) the correct paths for subsequent revisions. It's a mostly harmless side effect of copy/mv, but it is odd looking and seems sloppy from a purist point of view because something outside of the branch is changing the branch's history and baseline albeit in a mostly limited fashion. Isn't this just a difference in subversion's and your thinking about the significance of the path change? Subversion is going to see the path change affecting everything below it because of the way it holds projects together. Is there some reason you are changing a common parent path and thinking that it should not affect everything below? Is it 'above' what you think of as the actual project? Two words: meta data. A change in meta-data shouldn't change a branch's baseline. Moving /trunk to /project1/trunk shouldn't change the contents of the trunk baseline. Renaming a misspelled branch (/branches/rle1.0 to /branches/rel1.0) shouldn't change the contents of a branch/baseline. So, from a technical point of view, where svn has dirs, not branches, then yes, I would expect a parent dir change to do what it did. From a process/philosophical point of view where branches represent baselines, then I would not expect a parent dir change to do what it did. Anyway, it represents just one more potential quirk that you have to be aware of when using svn. Fortunately, it's mostly harmless. Long term, once svn's lower level features are mature (true renames, getting rid of --reintegrate, etc..) I would expect a push towards high-level process features such as branches as first class objects.
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Fri, May 10, 2013 at 10:42 AM, Andrew Reedick andrew.reed...@cbeyond.net wrote: Isn't this just a difference in subversion's and your thinking about the significance of the path change? Subversion is going to see the path change affecting everything below it because of the way it holds projects together. Is there some reason you are changing a common parent path and thinking that it should not affect everything below? Is it 'above' what you think of as the actual project? Two words: meta data. A change in meta-data shouldn't change a branch's baseline. Moving /trunk to /project1/trunk shouldn't change the contents of the trunk baseline. Renaming a misspelled branch (/branches/rle1.0 to /branches/rel1.0) shouldn't change the contents of a branch/baseline. How/why do you think of that differently than doing a similar directory move/rename somewhere under trunk? So, from a technical point of view, where svn has dirs, not branches, then yes, I would expect a parent dir change to do what it did. From a process/philosophical point of view where branches represent baselines, then I would not expect a parent dir change to do what it did. You think some directories are magically different (i.e. where your idea of a 'project' starts). Subversion doesn't. Anyway, it represents just one more potential quirk that you have to be aware of when using svn. Fortunately, it's mostly harmless. Long term, once svn's lower level features are mature (true renames, getting rid of --reintegrate, etc..) I would expect a push towards high-level process features such as branches as first class objects. I think it is one less thing to think about when all directories are handled the same way. -- Les Mikesell lesmikes...@gmail.com
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
-Steve -Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Friday, May 10, 2013 08:41 To: Andrew Reedick Cc: Branko Čibej; users@subversion.apache.org Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects? On Fri, May 10, 2013 at 10:20:54AM -0500, Andrew Reedick wrote: It makes me wonder if it would make sense to slap a higher-level interface on top of svn in order to implement the process aspects of version control (and otherwise hide/keep the lower level details/quirks away from users.) Yes, that makes sense. Subversion doesn't know anything about process. It only cares about version control. Process aspects are left to higher-level tools. With a toolset like Subversion, having a simple, elegant design is key for many benefits. There is definitely a trade-off between exposing the user interface at that level (basic operations add, cp, mv) versus exposing higher level concepts (branches, tags). Providing only the lower level stuff gives more flexibility for people to use it creatively and do things that might not be possible with higher-level, but more rigid concepts. Unfortunately, that also leaves us with having to define the higher level stuff ourselves. I support a big team (on the order of 150 engineers). They don't all have time to be svn experts, but to be productive team we all have to follow common conventions. I really miss not having branches and tags be first order objects. Subversion is more like a toolset and you have to build your own machine. (Or as we say, it's a box of rope. You can do a lot with rope, but sometimes you hang yourself.) As a version control tool, branches and tags seem like something that ought to be there, instead of merely conventions. But how I'd like to see there semantics work might be very different than other peoples'. So flexibility is a good thing. -Steve For example, Subversion is often tied to an issue tracker, with a pre- commit hook that requires an issue number in the log message and then checks the status if the issue to decide whether the commit should be allowed according to policy. Or people use hook scripts such as this one: http://svn.haxx.se/dev/archive-2012-04/0392.shtml http://svn.haxx.se/dev/archive-2012-04/0394.shtml I've also seen custom Subversion clients written to support a particular process.
