Mirror CVS commits to SVN
Hi I'm wondering if there is a script that can be used to mirror every commit done to a CVS server onto a SVN server. I was thinking of writing something that can be invoked by the CVS loginfo hook. Thanks!
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> On 05/18/2013 08:33 PM, David Chapman wrote: > > On 5/18/2013 12:01 PM, Zé wrote: > >> On 05/18/2013 07:16 PM, David Chapman wrote: > >>> > >>> You are pretty insistent that there is One True Way to use branches > >>> in development. > >> > >> No, I'm stating that if all a SCM does is track changes made to the > >> contents of a directory and you rely on changes made to that > >> directory to emulate branches, then there are some significant > >> downsides to this approach when compared with SCM systems which do > >> offer support for branching. > > > > You've missed the point. You have a specific definition of branching > > and do not believe that anything else can be called branching. > > You are confused. This discussion is about how subversion lacks any support > for > branching, which is quite obvious to anyone who understands and > acknowledges that all subversion does is track revision changes to a file > system. > What you are insistingly referring to as branches is nothing more than a copy > of > a particular subdirectory (i.e., the trunk) into another subdirectory (i.e., > branches), which is nothing more than a plain recursive directory copy > operation on a file system. The operation doesn't change its name or nature > (tag, trunk, simple server-side directory copy) depending on the directories > which are copied around the repository. Is that so hard for you to > understand? I disagree here. A branch is more than "a plain recursive directory copy operation on a file system." It has ancestry since it is pointed to its parent. This allows for merges from the parent to the branch. Svn log will show the revision history of a file from the branch back up to the parent path. Also blame goes back to the parent history as well. If a branch were "only a copy" then blame would only show, right after the branch, the person that made the branch. You keep saying "svn doesn't support branches" yet I use branches every day. While there is no way to "list branches" it would be possible. I think the current implementation records the parent path in the branch, but not vice versa... I assume svn doesn't do this because it would be a change to the parent path and the svn design avoids modifying the repository on its own. > > > > In your > > message to Thorsten Schöning, you said that branch history should be > > deleted if the branch is deleted. That is fundamentally in opposition > > to the definition of Subversion, which is meant to retain all of a > > project's history. > > Again, that's wrong. The only thing that leads subversion to track how a > subdirectory is copied around in the repository is the fact that this is not a > branching operation: this is nothing more than a plain file system operation. > > The point of this whole discussion is that subversion does not support > branching, > and therefore subversion users have to rely on the "let's copy the trunk > directory somewhere in the repo to simulate tags/branches" hack to make do. > Instead of relying on this hack, subversion would be significantly improved > if it > actually supported branches. How come you've replied so many times to this > discussion if you are so oblivious to what has been discussed so far? > > > > > -- > Zé
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> Guten Tag Zé, > am Sonntag, 19. Mai 2013 um 10:20 schrieben Sie: > > > You are confused. This discussion is about how subversion lacks any > > support for branching, which is quite obvious to anyone who > > understands and acknowledges that all subversion does is track > > revision changes to a file system.[...] Is that so hard for you to > > understand? > > It seems as hard to understand as it seems to be hard to understand for you > that you didn't ever gave any common specification what exactly a branch or > tag is. You said something about metadata, but gave no example what this > meta data is, besides a name, or why someone should benefit of only top level > branches and tags. Ze, Wait... did you say a few message ago that you don't think a branch is a branch, because when you delete the branch the history of the path is still in the repo? That's what your example seemed to show. I think people want obiliterate to deal with that issue. You can delete any path and still see it in the history if you ask for it.. Isn't keeping that history the whole point? BOb
svnlook cat seems to swallow byte order marks
Hi, it seems that svnlook cat swallows byte order marks (e.g. \xEF\xBB\xBF) from committed files. Therefore it is difficult to check for the presence or absence of BOMs in commit hooks. Can anyone confirm that this is a bug in Subversion (at least in version: 1.7.7)? -- Cheers Alex
Re: svnlook cat seems to swallow byte order marks
On 05/21/2013 10:53 AM, Alexander Veit wrote: > Hi, > > it seems that > > svnlook cat > > swallows byte order marks (e.g. \xEF\xBB\xBF) from committed files. Therefore > it is difficult to check for the presence or absence of BOMs in commit hooks. > > Can anyone confirm that this is a bug in Subversion (at least in version: > 1.7.7)? Nope. Works as expected here. $ svnlook cat data/repositories/i18n-data utf8-chinese-bom.txt > foo $ hexdump -C foo ef bb bf 75 74 66 38 2d 63 68 69 6e 65 73 65 2d |...utf8-chinese-| 0010 62 6f 6d 2d e5 90 8c e6 84 8f 0a |bom-...| 001b $ -- C. Michael Pilato CollabNet <> www.collab.net <> Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Tue, May 21, 2013 at 9:23 AM, Bob Archer wrote: >>> >> You are confused. This discussion is about how subversion lacks any support >> for >> branching, which is quite obvious to anyone who understands and >> acknowledges that all subversion does is track revision changes to a file >> system. >> What you are insistingly referring to as branches is nothing more than a >> copy of >> a particular subdirectory (i.e., the trunk) into another subdirectory (i.e., >> branches), which is nothing more than a plain recursive directory copy >> operation on a file system. The operation doesn't change its name or nature >> (tag, trunk, simple server-side directory copy) depending on the directories >> which are copied around the repository. Is that so hard for you to >> understand? > > > You keep saying "svn doesn't support branches" yet I use branches every day. > While there is no way to "list branches" it would be possible. I think the > current implementation records the parent path in the branch, but not vice > versa... Of course you can 'list branches' as long as you follow and remember _your_ convention for where they are. You can also delete them to the extent that they don't show up in this list (even though they can still be accessed with peg revision syntax and the actions show in the log history of the parent directory). This is nicer in many ways than just having one special-case 'branch' namespace, especially when you have many projects in the same repository and/or you like to separate your release, QA, and experimental branches so different groups don't have to deal with the clutter from the others. Subversion doesn't force you to follow good conventions (and I think this thread started because someone didn't and the rename of a directory above where they put a branch was recorded as a change in both the branch and its parent), but you can if you want. > I assume svn doesn't do this because it would be a change to the parent path > and the svn design avoids modifying the repository on its own. Subversion always tracks 'copy from', but not 'copy-to'. In one way it is correct to say that subversion doesn't have a special concept for branches, but it is equally correct to say that every copy is handled like a branch. -- Les Mikesell lesmikes...@gmail.com
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> -Original Message- > From: Bob Archer [mailto:bob.arc...@amsi.com] > Sent: Tuesday, May 21, 2013 10:24 AM > To: Zé; users@subversion.apache.org > Subject: RE: Subversion Doesn't Have Branches aka Crossing the Streams > aka Branches as First Class Objects? > > > .. snip > > You keep saying "svn doesn't support branches" yet I use branches every > day. While there is no way to "list branches" it would be possible. I > think the current implementation records the parent path in the branch, > but not vice versa... I assume svn doesn't do this because it would be > a change to the parent path and the svn design avoids modifying the > repository on its own. There are two definitions of branches; svn's definition of a branch (i.e. a dir) and the high-level definition of a branch (theory.) The reason why svn doesn't "support branches" is because a svn branch is just a dir, a dir that is only a branch because it is given special meaning by Humans. Internally, svn doesn't know or care if a dir is a branch or not. The distinction is important because one of the theoretical benefits of branching is isolation. An outside change shouldn't affect the branch's contents. Unfortunately, changing the parent path of a branch injects a spurious revision into 'svn log' and causes 'svn log --stop-on-copy' to stop early. This is detailed in my original email that started this thread. So when people say that svn doesn't have branches, they are saying that a) svn has directory objects, not branch objects, i.e. a svn branch is a branch by human convention only, b) svn dirs lack the special protections expected of branches (e.g. being isolated from outside change), c) svn dirs lack the special abilities expected of branches, such as computing ancestry reliably. Fortunately, in practice, "dirs-as-branches" works fine for the most part and any limitations tend to be minor. > While there is no way to "list branches" it would be possible. No-ish. In the average case, "list branches" is easy. Just iteratively run 'log --stop-on-copy'. However, there are edge cases that prevent "list branches" from being deterministic or otherwise make determining ancestry complicated. For example, is this a rename (to fix a misspelling) or a case where someone combined two steps: 1) creating a new branch and 2) deleting an obsolete branch? svn copy branches/ofo-1.0 branches/foo-1.0 svn rm branches/ofo-1.0 svn ci ... creates revision 100 ... If I want to find the start of the branch, I run 'svn log --stop-on-copy ^/branches/foo-1.0' which will stop on revision 100. However, svn can't tell me if rev 100 is the start of the branch or whether it's just a spelling fix (in which case I need to run 'svn log --stop-on-copy' again.) Hopefully, the Human who created rev 100 provided a meaningful commit message.
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> On Tue, May 21, 2013 at 9:23 AM, Bob Archer wrote: > >>> > >> You are confused. This discussion is about how subversion lacks any > >> support for branching, which is quite obvious to anyone who > >> understands and acknowledges that all subversion does is track revision > changes to a file system. > >> What you are insistingly referring to as branches is nothing more > >> than a copy of a particular subdirectory (i.e., the trunk) into > >> another subdirectory (i.e., branches), which is nothing more than a > >> plain recursive directory copy operation on a file system. The > >> operation doesn't change its name or nature (tag, trunk, simple > >> server-side directory copy) depending on the directories which are copied > around the repository. Is that so hard for you to understand? > > > > > > You keep saying "svn doesn't support branches" yet I use branches every day. > While there is no way to "list branches" it would be possible. I think the > current > implementation records the parent path in the branch, but not vice versa... > > Of course you can 'list branches' as long as you follow and remember _your_ > convention for where they are. You can also delete them to the extent that > they > don't show up in this list (even though they can still be accessed with peg > revision syntax and the actions show in the True, I can look at the branches folder. However, we keep branches for all revisions in the same branches folder. What I meant is I can't be in a working copy with a repo path of ^/trunk and have it tell me what branches (copies) have been made from that path. Once again, a nice to have, but not a must have... since yes, our naming conventions are sufficient to identify the info we need. > log history of the parent directory). This is nicer in many ways > than just having one special-case 'branch' namespace, especially when you > have many projects in the same repository and/or you like to separate your > release, QA, and experimental branches so different groups don't have to deal > with the clutter from the others. > Subversion doesn't force you to follow good conventions (and I think this > thread > started because someone didn't and the rename of a directory above where > they put a branch was recorded as a change in both the branch and its parent), > but you can if you want. > > > I assume svn doesn't do this because it would be a change to the parent path > and the svn design avoids modifying the repository on its own. > > Subversion always tracks 'copy from', but not 'copy-to'. In one way > it is correct to say that subversion doesn't have a special concept for > branches, > but it is equally correct to say that every copy is handled like a branch. Right, so this "copy-from" info is exactly what makes the "copy" a "branch" or more than just a file system copy. that's the point I was trying to make. > > -- > Les Mikesell > lesmikes...@gmail.com
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> > .. snip > > > > You keep saying "svn doesn't support branches" yet I use branches > > every day. While there is no way to "list branches" it would be > > possible. I think the current implementation records the parent path > > in the branch, but not vice versa... I assume svn doesn't do this > > because it would be a change to the parent path and the svn design > > avoids modifying the repository on its own. > > There are two definitions of branches; svn's definition of a branch (i.e. a > dir) > and the high-level definition of a branch (theory.) The reason why svn > doesn't > "support branches" is because a svn branch is just a dir, a dir that is only a > branch because it is given special meaning by Humans. Internally, svn doesn't > know or care if a dir is a branch or not. > > The distinction is important because one of the theoretical benefits of > branching is isolation. An outside change shouldn't affect the branch's > contents. Unfortunately, changing the parent path of a branch injects a > spurious revision into 'svn log' and causes 'svn log --stop-on-copy' to stop > early. > This is detailed in my original email that started this thread. True but doesn't the log of ^/projectname1/trunk also change when you commit something to ^/projectname2/trunk ?? Projects aren't isolated within the same repo either. > > So when people say that svn doesn't have branches, they are saying that > a) svn has directory objects, not branch objects, i.e. a svn branch is a > branch by > human convention only, > b) svn dirs lack the special protections expected of branches (e.g. being > isolated > from outside change), > c) svn dirs lack the special abilities expected of branches, such as computing > ancestry reliably. > > Fortunately, in practice, "dirs-as-branches" works fine for the most part and > any > limitations tend to be minor. > > > > While there is no way to "list branches" it would be possible. > > No-ish. In the average case, "list branches" is easy. Just iteratively run > 'log -- > stop-on-copy'. However, there are edge cases that prevent "list branches" > from > being deterministic or otherwise make determining ancestry complicated. > > For example, is this a rename (to fix a misspelling) or a case where someone > combined two steps: 1) creating a new branch and 2) deleting an obsolete > branch? > svn copy branches/ofo-1.0 branches/foo-1.0 > svn rm branches/ofo-1.0 > svn ci > ... creates revision 100 ... > > If I want to find the start of the branch, I run 'svn log --stop-on-copy > ^/branches/foo-1.0' which will stop on revision 100. However, svn can't tell > me > if rev 100 is the start of the branch or whether it's just a spelling fix (in > which > case I need to run 'svn log --stop-on-copy' again.) Hopefully, the Human who > created rev 100 provided a meaningful commit message. > > >
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> Guten Tag Andreas Krey, > am Samstag, 18. Mai 2013 um 22:41 schrieben Sie: > > > You mean like 'I expect tags to be immutable out of the box, and have > > the VCS not modify them with perfectly normal operations, at least not > > without adding -f or something to them'? > > This sounds like Subversion technically supports tags, just with the caveat > that > you have to deal with "-f" yourself. From my use case I like that tags are > writable by default because that's what I need. Although, truly if there was a "tag" command that added metadata to a revision which I think someone showed an example of earlier in this thread, you could still use the "copy" command to get a writeable tag directory like you have now. Frankly, if you are writing to tags it is more like a branch. ;) BOb
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> -Original Message- > From: Johan Corveleyn [mailto:jcor...@gmail.com] > Sent: Saturday, May 18, 2013 4:17 PM > To: Zé > Cc: users@subversion.apache.org; David Chapman > Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams > aka Branches as First Class Objects? > > So what's the actual problem (or problems) with SVN's branching and > tagging? Where does it hurt your workflow? What would make SVN not > "hurt you" in that way? > > Please be concrete, and give examples of what really bothers you as a > user or an admin in your daily work. Saying that "branches are not > first class", or "I don't like it that Subversion implements > branches/tags by copying directories" are too abstract, and really not > relevant. Why should I care how SVN implements its branches internally, > as long as it works for the use cases I need? > > The only concrete problem I've read so far (I don't remember if it was > in this thread or another one) is that copying the parent of all > branches (or tags) shows up as a revision when you "svn log" the > branch. So okay, that's one thing. Any others? > Correct, changing the parent dir of a branch injects a "spurious" log entry in your branches (or tags) sub dirs, which is morally wrong because branches (and tags) should be isolated from outside changes. I documented this in the original post. (Or, given "^/porject1/branches" and "^/porject1/tags", if you "svn copy ^/porject1 ^/project" to fix the naming problem then everything under branches and tags gets the spurious revision. The spurious revision also triggers on --stop-on-copy which needlessly complicates ancestry tracking. However, given how svn works, I'm not sure that it is technically a technical issue. =) Instead, is it a "branches as first class objects" requirement? > > However, this discussion lacks focus, it sounds more like a > philosophical debate, with large ideas being thrown against each other. > If you want to get anything useful out of this discussion (be it > planting the seeds for improvements to Subversion, or be it a deeper > understanding for yourself of how to work effectively with svn), you'll > have to get much more concrete. IMO, it's not a philosophical debate per se, it's a requirements (or expectations) problem. We have two points of view. The first is the low-level technical point of view that is focused on being able to perform any operation at any point in the repository tree. The second is the high-level point of view that needs a VCS to manage baselines, track ancestry, track merges between baselines, etc. IMO, subversion right now is more of a VCS engine than a VCS "system." Basically, it's the trees versus the forest view. The friction is that the high-level point of view folks are probably your primary customers. For example, when Subversion initially announced that merge tracking wasn't part of the initial architecture, I laughed and blew off svn as a complete waste of time due to intentionally lacking such a basic and essential VCS feature. Now that svn has implemented merge tracking, tree merging, and the long overdue death of --reintegrate in 1.8, I think it's getting close to the point that svn needs to step back and consider the forest view, e.g. true branches, proper ancestry tracking (instead of --stop-on-copy), etc., in order to maintain relevance. Meaning, svn's paradigm/workflow will need to focus on baselines (aka branches) instead of files and dirs because, in my experience, VCS users are most concerned about slinging baselines around and tracking changes to baselines (i.e. has all work for the release (baseline) been completed, merged, and tested?) Disclaimer: All IMHO.
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
Guten Tag Bob Archer, am Dienstag, 21. Mai 2013 um 17:54 schrieben Sie: > Frankly, if you are > writing to tags it is more like a branch. ;) Of course, that's why it's all about definitions or conventions and my writable tags are customer installations of our software which get updated to new versions and are used to track configuration changes. Nothing I would like to implement using only top level branches and as no active development takes place on those directories, I see them rather as tags, than branches. 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: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> -Original Message- > From: Thorsten Schöning [mailto:tschoen...@am-soft.de] > Sent: Tuesday, May 21, 2013 12:30 PM > To: users@subversion.apache.org > Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams > aka Branches as First Class Objects? > > Guten Tag Bob Archer, > am Dienstag, 21. Mai 2013 um 17:54 schrieben Sie: > > > Frankly, if you are > > writing to tags it is more like a branch. ;) > > Of course, that's why it's all about definitions or conventions and my > writable tags are customer installations of our software which get > updated to new versions and are used to track configuration changes. > Nothing I would like to implement using only top level branches and as > no active development takes place on those directories, I see them > rather as tags, than branches. > I think of tag-branches as effort saving devices that spare me from having to svn copy tags/PRODUCTION branches/production vi branches/production/config.conf ... svn rm tags/PRODUCTION svn copy branches/production tags/PRODUCTION when a hostname changes in prod and I need to backfill a config file. Should we call them tag-branches or branch-tags? And should they be first class objects? ;-)
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Tue, May 21, 2013 at 10:54 AM, Bob Archer wrote: >> >> > You mean like 'I expect tags to be immutable out of the box, and have >> > the VCS not modify them with perfectly normal operations, at least not >> > without adding -f or something to them'? >> >> This sounds like Subversion technically supports tags, just with the caveat >> that >> you have to deal with "-f" yourself. From my use case I like that tags are >> writable by default because that's what I need. > > Although, truly if there was a "tag" command that added metadata to a > revision which I think someone showed an example of earlier in this thread, > you could still use the "copy" command to get a writeable tag directory like > you have now. Frankly, if you are writing to tags it is more like a branch. ;) > We sometimes like to tag a source revision, then add the resulting binaries after the fact. Conceptually that's not a real change but more of just the way things work. And we are moving towards letting Jenkins build from the trunk or a branch, then using a plugin to tag after a successful build. But,.I still miss the way CVS let you easily 'float' known tag names to revisions (even mixed, cherry-picked workspaces) to target subsequent operations like your nightly build or the rollback version as you advance a deployment. Simulating that by deleting and making a new tag seems awkward. Since tag names are what you use by convention, if you wanted immutable tags you could just as easily use /path/tags/tag_name@revision as the name which will always contain the same thing. It's not really any harder to pass around than any other arbitrary name. -- Les Mikesell lesmikes...@gmail.com
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> > So what's the actual problem (or problems) with SVN's branching and > > tagging? Where does it hurt your workflow? What would make SVN not > > "hurt you" in that way? > > > > Please be concrete, and give examples of what really bothers you as a > > user or an admin in your daily work. Saying that "branches are not > > first class", or "I don't like it that Subversion implements > > branches/tags by copying directories" are too abstract, and really not > > relevant. Why should I care how SVN implements its branches > > internally, as long as it works for the use cases I need? > > > > The only concrete problem I've read so far (I don't remember if it was > > in this thread or another one) is that copying the parent of all > > branches (or tags) shows up as a revision when you "svn log" the > > branch. So okay, that's one thing. Any others? > > > > Correct, changing the parent dir of a branch injects a "spurious" log entry in > your branches (or tags) sub dirs, which is morally wrong because branches (and > tags) should be isolated from outside changes. I documented this in the > original post. (Or, given "^/porject1/branches" and "^/porject1/tags", if you > "svn copy ^/porject1 ^/project" to fix the naming problem then everything > under branches and tags gets the spurious revision. The spurious revision > also > triggers on --stop-on-copy which needlessly complicates ancestry tracking. > > However, given how svn works, I'm not sure that it is technically a technical > issue. =) Instead, is it a "branches as first class objects" requirement? What do you mean by "spurious" log entries? When I look at the log (at least in the tsvn log viewer) I only see revisions that have changes on that path. I don't see every revision number unless I go to the project root path or repository root path. <>
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> -Original Message- > From: Bob Archer [mailto:bob.arc...@amsi.com] > Sent: Tuesday, May 21, 2013 1:24 PM > To: Andrew Reedick; Johan Corveleyn > Cc: users@subversion.apache.org; David Chapman > Subject: RE: Subversion Doesn't Have Branches aka Crossing the Streams > aka Branches as First Class Objects? > > > What do you mean by "spurious" log entries? When I look at the log (at > least in the tsvn log viewer) I only see revisions that have changes on > that path. I don't see every revision number unless I go to the project > root path or repository root path. > 1. Create /tags/tag1, /tags/tag2, etc.. 2. Pretend that your tag1, tag2, etc. dirs are immutable, static, locked down, and haven't be touched in months. 3. svn log -v --stop-on-copy ^/tags/tag1 svn log -v --stop-on-copy ^/tags/tag2 etc. 4. # Move your tags dir under a project1 dir svn mv -m "" --parents ^/tags ^/project1/tags 5. svn log -v --stop-on-copy ^/project1/tags/tag1 svn log -v --stop-on-copy ^/project1/tags/tag2 etc. Ooops. All of your immutable, static, locked down, haven't been touched in months tags now have a new revision, and they all share that revision in common. The parent dir change from "/tags" to "/project1/tags" is visible under the tag1, tag2, etc. baselines because svn doesn't know that "^/project1/tags" isn't/shouldn't be part of your "tag1", "tag2", etc. baselines. However, the Last Changed Revision of the tag1, tag2, etc. dirs doesn't change, so the effect is mostly visual.
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: Tuesday, May 21, 2013 11:41 AM > To: Bob Archer > Cc: Zé; users@subversion.apache.org > Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams > aka Branches as First Class Objects? > > > Of course you can 'list branches' as long as you follow and remember > _your_ convention for where they are. You can also delete them to the > extent that they don't show up in this list (even though they can still > be accessed with peg revision syntax and the actions show in the > log history of the parent directory). This is nicer in many ways > than just having one special-case 'branch' namespace, especially when > you have many projects in the same repository and/or you like to > separate your release, QA, and experimental branches so different > groups don't have to deal with the clutter from the others. > Subversion doesn't force you to follow good conventions (and I think > this thread started because someone didn't and the rename of a > directory above where they put a branch was recorded as a change in > both the branch and its parent), but you can if you want. > Right, right, it's the user's fault for failing to predict future "namespace" needs. That the repository was created when the project was small and that the user in question inherited the repo aren't valid excuses either. Next time I'll implement top level directory changes via 'svnadmin dump/load' to avoid spurious log entries under branches/tags. Translation: Les, that wasn't a very realistic or helpful piece of advice.
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Tue, May 21, 2013 at 12:50 PM, Andrew Reedick wrote: > >> What do you mean by "spurious" log entries? When I look at the log (at >> least in the tsvn log viewer) I only see revisions that have changes on >> that path. I don't see every revision number unless I go to the project >> root path or repository root path. >> > > 1. Create /tags/tag1, /tags/tag2, etc.. > 2. Pretend that your tag1, tag2, etc. dirs are immutable, static, locked > down, and haven't be touched in months. > 3. svn log -v --stop-on-copy ^/tags/tag1 >svn log -v --stop-on-copy ^/tags/tag2 >etc. > 4. # Move your tags dir under a project1 dir >svn mv -m "" --parents ^/tags ^/project1/tags What operation would this correspond to in a VCS that had 'first class' tags? Should svn disallow it to emulate them? > Ooops. All of your immutable, static, locked down, haven't been touched in > months tags now have a new revision, and they all share that revision in > common. The parent dir change from "/tags" to "/project1/tags" is visible > under the tag1, tag2, etc. baselines because svn doesn't know that > "^/project1/tags" isn't/shouldn't be part of your "tag1", "tag2", etc. > baselines. > > However, the Last Changed Revision of the tag1, tag2, etc. dirs doesn't > change, so the effect is mostly visual. Isn't it really just an artifact of using --stop-on-copy to mean something it doesn't quite mean - or more practically an artifact of having done a copy that might have been avoided with better planning or conventions? Is there some documentation that recommends moving the parent location of the tags after creating them? And again, in a practical sense, would you prefer for subversion to have disallowed that move? Or can you at least acknowledge that it didn't force you to do it? -- Les Mikesell lesmikes...@gmail.com
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 21.05.2013 19:50, Andrew Reedick wrote: > Ooops. All of your immutable, static, locked down, haven't been touched in > months tags now have a new revision, and they all share that revision in > common. The parent dir change from "/tags" to "/project1/tags" is visible > under the tag1, tag2, etc. baselines because svn doesn't know that > "^/project1/tags" isn't/shouldn't be part of your "tag1", "tag2", etc. > baselines. In fact, it should, because you renamed the tags. The misconception is that the names of the tags is "tag1" and "tag2"; that is not the case. The names are /tags/tag1 and /tags/tag2 before the rename, and whatever the paths are after the rename. You cannot identify a directory (or branch or tag) just by its basename, only the whole path is a unique identifier (within the repository). -- 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 21.05.2013 20:26, Branko Čibej wrote: > On 21.05.2013 19:50, Andrew Reedick wrote: >> Ooops. All of your immutable, static, locked down, haven't been touched in >> months tags now have a new revision, and they all share that revision in >> common. The parent dir change from "/tags" to "/project1/tags" is visible >> under the tag1, tag2, etc. baselines because svn doesn't know that >> "^/project1/tags" isn't/shouldn't be part of your "tag1", "tag2", etc. >> baselines. > In fact, it should, because you renamed the tags. The misconception is > that the names of the tags is "tag1" and "tag2"; that is not the case. > The names are /tags/tag1 and /tags/tag2 before the rename, and whatever > the paths are after the rename. > > You cannot identify a directory (or branch or tag) just by its basename, > only the whole path is a unique identifier (within the repository). Just to be clear -- I agree that the the result of 'svn log --stop-on-copy' changes is confusing. And, as I said (much) earlier in this thread, that's an unfortunate side effect of how renames are currently implemented. Personally I've always viewed the --stop-on-copy as a hack, and we really should invent a better way of identifying branch points. -- 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 Tue, May 21, 2013 at 1:13 PM, Andrew Reedick wrote: > > Right, right, it's the user's fault for failing to predict future "namespace" > needs. That the repository was created when the project was small and that > the user in question inherited the repo aren't valid excuses either. Your bigger problem will come when you add enough projects that the size of the repository becomes impractical to manage. Then it will be your fault for not predicting the growth... > Next time I'll implement top level directory changes via 'svnadmin dump/load' > to avoid spurious log entries under branches/tags. And you'll find that is less than perfect too if you want to extract and move things that did not have stable parent paths. > Translation: Les, that wasn't a very realistic or helpful piece of advice. I'd call realizing that most software isn't perfect being realistic, and learning to live with the imperfections to be more helpful than waiting for everything to work the way you expect. Maybe in this specific case some kind of event metadata could be added to note your intent to create a branch or tag and that could be used instead of --stop-on-copy to avoid confusing what you think of as tags and other copies. -- Les Mikesell lesmikes...@gmail.com
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: Tuesday, May 21, 2013 2:33 PM > To: Andrew Reedick > Cc: users@subversion.apache.org > Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams > aka Branches as First Class Objects? > > > I'd call realizing that most software isn't perfect being realistic, > and learning to live with the imperfections to be more helpful than > waiting for everything to work the way you expect. Maybe in this > specific case some kind of event metadata could be added to note your > intent to create a branch or tag and that could be used instead of -- > stop-on-copy to avoid confusing what you think of as tags and other > copies. > Metadata could work. A "svn mkbranch" command that would run "svn copy" plus "svn propset" indicating that this is a branch root. "svn copy" would be restricted from operating in the branches or tags dir (as indicated by another property.) "svn log --stop-on-branch" would then check for the metadata. Although if I was going to modify the client that much, I might as well internally store branches as "^/UUID" and map the UUIDs to a human label, e.g. "project1/1.0" or "project1/trunk". That would eliminate the troublesome "admin" level dirs from the repo and essentially implement "true branches"? And this would only be a presentation change thus negating the need to change how svn works internally.
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: Tuesday, May 21, 2013 2:32 PM > To: users@subversion.apache.org > Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams > aka Branches as First Class Objects? > > On 21.05.2013 20:26, Branko Čibej wrote: > > > > You cannot identify a directory (or branch or tag) just by its > > basename, only the whole path is a unique identifier (within the > repository). Yes, I understand why it happens and why it needs to happen. > Just to be clear -- I agree that the the result of 'svn log --stop-on- > copy' changes is confusing. And, as I said (much) earlier in this > thread, that's an unfortunate side effect of how renames are currently > implemented. Personally I've always viewed the --stop-on-copy as a > hack, and we really should invent a better way of identifying branch > points. > I don't think true renames will necessarily fix the problem. Conceptually, the problem is that the parent dir components of a branch/tag are superfluous, e.g. given "svn://server/repo/path/to/project1/branches/1.0", the "svn://server/repo/path/to" and "branches" path components are useless/meaningless to the average user. However, these superfluous dir components are visible to the client, which means they're accessible by, and thus modifiable by the client. Which makes them superfluous *and* dangerous. The client should only see and work with "--project project1 --branch 1.0", e.g. "svn co --project project1 --branch 1.0" to checkout a branch. It's about presentation. Keep the superfluous dir components internal and hidden from the average user. We've already seen a move towards information hiding with the'^' syntax that hides the server component. This would be the logical progression. Anyway, I'm nearly done with implementing my "find common ancestor" script that seems resistant to edge conditions, so I'll stop rambling.
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 21.05.2013 21:27, Andrew Reedick wrote: > Anyway, I'm nearly done with implementing my "find common ancestor" > script that seems resistant to edge conditions, so I'll stop rambling. Ah ... if that's what started the whole thread ... have you considered that the Subversion libraries already have that functionality, and that it's accessible through a number of script language wrappers? -- 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?
> -Original Message- > From: Branko Čibej [mailto:br...@wandisco.com] > Sent: Tuesday, May 21, 2013 3:36 PM > To: users@subversion.apache.org > Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams > aka Branches as First Class Objects? > > On 21.05.2013 21:27, Andrew Reedick wrote: > > Anyway, I'm nearly done with implementing my "find common ancestor" > > script that seems resistant to edge conditions, so I'll stop > rambling. > > Ah ... if that's what started the whole thread ... have you considered > that the Subversion libraries already have that functionality, and that > it's accessible through a number of script language wrappers? > Will the libraries get tripped up by "spurious" revisions created by parent dir path changes?
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Tue, May 21, 2013 at 2:27 PM, Andrew Reedick wrote: > > I don't think true renames will necessarily fix the problem. Conceptually, > the problem is that the parent dir components of a branch/tag are > superfluous, e.g. given "svn://server/repo/path/to/project1/branches/1.0", > the "svn://server/repo/path/to" and "branches" path components are > useless/meaningless to the average user. Well, no. If I copy something from /proj1/branches/dev/branch001 to /proj1/branches/qa/branch001 or on to /proj1/branches/prod/branch001 it isn't meaningless even though at the time of the initial copy and possibly forever the contents are identical. 'Meaning' is imposed by the user, not the tool. > However, these superfluous dir components are visible to the client, which > means they're accessible by, and thus modifiable by the client. Which makes > them superfluous *and* dangerous. No, it makes them useful. > The client should only see and work with "--project project1 --branch 1.0", > e.g. "svn co --project project1 --branch 1.0" to checkout a branch. That's sort of like saying filesystems shouldn't have subdirectories so users don't get confused... Some people might even believe that. > It's about presentation. Keep the superfluous dir components internal and > hidden from the average user. We've already seen a move towards information > hiding with the'^' syntax that hides the server component. This would be the > logical progression. It's about organization. And letting you arrange your own conventions to match your processes. -- Les Mikesell lesmikes...@gmail.com
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: Tuesday, May 21, 2013 3:53 PM > 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? > > > > The client should only see and work with "--project project1 --branch > 1.0", e.g. "svn co --project project1 --branch 1.0" to checkout a > branch. > > That's sort of like saying filesystems shouldn't have subdirectories so > users don't get confused... Some people might even believe that. And there's a reason why 'pwd' returns '/home/userid' instead of '/dev/sda1/home/userid' or 'server-vol0.foo.net:/vol0/userid'. Or why 'cd ~' takes you to your home dir. > > > It's about presentation. Keep the superfluous dir components > internal and hidden from the average user. We've already seen a move > towards information hiding with the'^' syntax that hides the server > component. This would be the logical progression. > > It's about organization. And letting you arrange your own conventions > to match your processes. We'll have to agree to disagree. We're back at the low level "managing dirs" versus high-level "managing baselines" arguments/thinking/paradigms.
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> From: Andrew Reedick >> -Original Message- >> From: Les Mikesell [mailto:lesmikes...@gmail.com] >> Sent: Tuesday, May 21, 2013 3:53 PM >> 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? >> >> >> > The client should only see and work with "--project project1 > --branch >> 1.0", e.g. "svn co --project project1 --branch 1.0" to > checkout a >> branch. >> >> That's sort of like saying filesystems shouldn't have > subdirectories so >> users don't get confused... Some people might even believe that. > > And there's a reason why 'pwd' returns '/home/userid' > instead of '/dev/sda1/home/userid' or > 'server-vol0.foo.net:/vol0/userid'. Or why 'cd ~' takes you to > your home dir. Well, "cd ~" is imposed by the shell environment, not by kernel. And /dev/sda1 being / is imposed by the kernel, not the shell; but the kernel only knew to map it that way because the user told it to. The issue is the same as with SVN. SVN does not know anything about what users mean by the URL paths; it only knows about the paths it implements. A higher level piece of software could do additional mappings and hide all those details - just like the kernel does for user level programs when it is told to map /dev/sda1 to /; but that higher level piece of software has to be configured to do that, just like the kernel does. >> > It's about presentation. Keep the superfluous dir components >> internal and hidden from the average user. We've already seen a move >> towards information hiding with the'^' syntax that hides the server >> component. This would be the logical progression. >> >> It's about organization. And letting you arrange your own conventions >> to match your processes. > We'll have to agree to disagree. We're back at the low level > "managing dirs" versus high-level "managing baselines" > arguments/thinking/paradigms. As others have stated, SVN provides the engine to do the work - just like the kernel provides the engine to read the disk drive. However, unlike the kernel it has no higher level functions that do mappings it can understand. It's just the core, and while it is pretty smart about what it does it is also pretty dumb about what it doesn't do - just like a kernel file system driver is very smart about reading the file system but very stupid about what the directories or files the user puts in the file system mean. Or more to the point, you can think of it like this: Apache2 = Kernel - maps https://mysvnserver/svnrepopath to / SVN = File System Driver for the kernel Of course, "svnserve" mixes the two, but that's really the gist of it as it relates to your example. Ben
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Tue, May 21, 2013 at 3:32 PM, Andrew Reedick wrote: > > We'll have to agree to disagree. We're back at the low level "managing dirs" > versus high-level "managing baselines" arguments/thinking/paradigms. > We're not completely opposed here. I can see the value of being able to note the 'top' of where you think a branch starts and constrain subsequent 'branch related' operations to that and things with the same parent revision history.But I can also see the value of being able to organize your branches under a parent tree to separate qa/release/feature/experimental/etc. sections, so I don't think completely hiding the path to branches is the right answer.And given subversion's ability to check out directories 'above' your project or branch level, I don't see how you can avoid a literal mapping into directories even if that doesn't match the more typical use. In any case, if you have ever published/announced a URL to your branch to the group that will use it, you have a bigger problem than with the tool itself if you change that location after the fact. Rather than trying to change history with a move you want to pretend didn't happen, maybe it would be better to just do a copy and have everyone aware that the location is new. -- Les Mikesell lesmikes...@gmail.com
Re: svnlook cat seems to swallow byte order marks
C. Michael Pilato wrote on Tue, May 21, 2013 at 11:07:00 -0400: > On 05/21/2013 10:53 AM, Alexander Veit wrote: > > Hi, > > > > it seems that > > > > svnlook cat > > > > swallows byte order marks (e.g. \xEF\xBB\xBF) from committed files. > > Therefore it is difficult to check for the presence or absence of BOMs in > > commit hooks. > > > > Can anyone confirm that this is a bug in Subversion (at least in version: > > 1.7.7)? svn info ^/foo | grep Checksum: and svnlook cat . foo | openssl md5 should produce the same output. Do they for you, Alexander?
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
Guten Tag Andrew Reedick, am Dienstag, 21. Mai 2013 um 21:27 schrieben Sie: > It's about presentation. Keep the superfluous dir components > internal and hidden from the average user. Clearly a -1/dislike from me. :-) 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: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
Les Mikesell wrote on Tue, May 21, 2013 at 16:04:59 -0500: > In any case, if you have ever published/announced a URL to your branch > to the group that will use it, you have a bigger problem than with the > tool itself if you change that location after the fact. Rather than > trying to change history with a move you want to pretend didn't > happen, maybe it would be better to just do a copy and have everyone > aware that the location is new. ASF Infra have an httpd module that intercepts attempts to access a URL that has been moved (^/incubator/bar/foo to ^/baz/foo) and issues a permanent redirect (301) response: https://svn.apache.org/repos/infra/infrastructure/trunk/projects/svn_check_path/README
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Tue, May 21, 2013 at 4:19 PM, Daniel Shahaf wrote: > Les Mikesell wrote on Tue, May 21, 2013 at 16:04:59 -0500: >> In any case, if you have ever published/announced a URL to your branch >> to the group that will use it, you have a bigger problem than with the >> tool itself if you change that location after the fact. Rather than >> trying to change history with a move you want to pretend didn't >> happen, maybe it would be better to just do a copy and have everyone >> aware that the location is new. > > ASF Infra have an httpd module that intercepts attempts to access a URL > that has been moved (^/incubator/bar/foo to ^/baz/foo) and issues > a permanent redirect (301) response: > > https://svn.apache.org/repos/infra/infrastructure/trunk/projects/svn_check_path/README Does that actually work with svn clients? Some time ago I tried to do a reverse-proxy in apache to a repository hosted on a different server and it worked when the target path was the same on the remote as what the client requested but when the path was different and mapped in the proxy, somehow the 'real' path leaked back to the client and kept it from working for some operations. Maybe in this case if they learn the real path it just works anyway. -- Les Mikesell lesmikes...@gmail.com
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
Les Mikesell wrote on Tue, May 21, 2013 at 16:40:40 -0500: > On Tue, May 21, 2013 at 4:19 PM, Daniel Shahaf > wrote: > > Les Mikesell wrote on Tue, May 21, 2013 at 16:04:59 -0500: > >> In any case, if you have ever published/announced a URL to your branch > >> to the group that will use it, you have a bigger problem than with the > >> tool itself if you change that location after the fact. Rather than > >> trying to change history with a move you want to pretend didn't > >> happen, maybe it would be better to just do a copy and have everyone > >> aware that the location is new. > > > > ASF Infra have an httpd module that intercepts attempts to access a URL > > that has been moved (^/incubator/bar/foo to ^/baz/foo) and issues > > a permanent redirect (301) response: > > > > https://svn.apache.org/repos/infra/infrastructure/trunk/projects/svn_check_path/README > > Does that actually work with svn clients? Some time ago I tried to > do a reverse-proxy in apache to a repository hosted on a different That module just sends a 301 response, it doesn't try to transparently proxy anything. Daniel > server and it worked when the target path was the same on the remote > as what the client requested but when the path was different and > mapped in the proxy, somehow the 'real' path leaked back to the client > and kept it from working for some operations. Maybe in this case if > they learn the real path it just works anyway. > > -- >Les Mikesell > lesmikes...@gmail.com
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Tue, May 21, 2013 at 03:20:37PM -0400, Andrew Reedick wrote: > Metadata could work. A "svn mkbranch" command that would run "svn > copy" plus "svn propset" indicating that this is a branch root. More than a week ago, this exact idea was already mentioned: http://svn.haxx.se/users/archive-2013-05/0109.shtml In the *same* mailing list thread. Looks like this discussion has entered an infinite loop.
Use Subversion to Manage Git?
Hi All, My apologies if this has been asked. A search of the archives doe not show anything recent, and Google is returning a lot of spurious hits. I'd like to use Subversion to manage a Git. Is anyone aware of a plugin that offers the extensions? I was thinking something like: `svn checkout git://...`. After the initial checkout, subversion would know its a git repo and translate subversion commands to git. It would be great if it could handle something like: `svn checkout -git ssh://j...@example.com//opt/repo.git`. I only need four or five basic commands - checkout, update, commit, add (files), remove (files). I would like to use subversion to manage git it because I'm happy with subversion (I understand the workflow and know the commands), git baffles me due to its workflow and out-of-the-box complexity (I have no clue as to what most of [1] talks about, or why I have to do it after a checkout), I don't have the time to read the book at the moment (the man pages suck, and I have no spare cycles for the next 6 or 8 weeks or so), and I can no longer avoid git (in the past, I simply walked away because it was not worth the aggravation). Jeff [1] http://stackoverflow.com/questions/572549/difference-of-git-add-a-and-git-add
Re: Use Subversion to Manage Git?
On Tue, 21 May 2013 21:55:51 +, Jeffrey Walton wrote: ... > I only need four or five basic commands - > checkout, git clone $repo > update, git pull --rebase (after committing your own stuff) > commit, git commit -a && git push (after a pull) > add (files), git add files > remove (files). git rm files Looks easier than hunting down a nonexistent plugin. Otherwise, take a look at svnhub.com. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Use Subversion to Manage Git?
On Tue, May 21, 2013 at 09:55:51PM -0400, Jeffrey Walton wrote: > Hi All, > > My apologies if this has been asked. A search of the archives doe not > show anything recent, and Google is returning a lot of spurious hits. > > I'd like to use Subversion to manage a Git. Is anyone aware of a > plugin that offers the extensions? I was thinking something like: `svn > checkout git://...`. After the initial checkout, subversion would know > its a git repo and translate subversion commands to git. It would be > great if it could handle something like: `svn checkout -git > ssh://j...@example.com//opt/repo.git`. > I am not aware of such a thing. In Subversion terms, this would require writing libsvn_ra_git --- i.e., a wire protocol client module. (But read on...) > I only need four or five basic commands - checkout, update, commit, > add (files), remove (files). > It sounds like what you are really looking for is a git cheatsheet for those five commands (e.g., 'git commit -amm && git push'), or a wrapper around git(1) that tweaks the UI (these seem to crop up every so often), or... You could look into using another DVCS to interact with Git repositories; for example: http://mercurial.selenic.com/wiki/HgGit http://doc.bazaar.canonical.com/migration/en/foreign/bzr-on-git-projects.html Daniel > I would like to use subversion to manage git it because I'm happy with > subversion (I understand the workflow and know the commands), git > baffles me due to its workflow and out-of-the-box complexity (I have > no clue as to what most of [1] talks about, or why I have to do it > after a checkout), I don't have the time to read the book at the > moment (the man pages suck, and I have no spare cycles for the next 6 > or 8 weeks or so), and I can no longer avoid git (in the past, I > simply walked away because it was not worth the aggravation). > > Jeff > > [1] > http://stackoverflow.com/questions/572549/difference-of-git-add-a-and-git-add
Re: Use Subversion to Manage Git?
Guten Tag Jeffrey Walton, am Mittwoch, 22. Mai 2013 um 03:55 schrieben Sie: > I only need four or five basic commands - checkout, update, commit, > add (files), remove (files). Those things are equally easy using git, simply look for comparisons of the main commands of the two worlds. Besides that, depending on your OS, IDE etc. simply use a GUI tool which will abstract everything. TortoiseGIT is actually usable. http://git.or.cz/course/svn.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
