On 05/21/2013 06:10 PM, Stefan Sperling wrote:
Looks like this discussion has entered an infinite loop.
... which is a pity, because certain whole arcs of that loop are arguably
off-topic for a users@ list. Design-related discussions really belong on dev@.
--
C. Michael Pilato
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
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
On Tue, May 21, 2013 at 9:23 AM, Bob Archer bob.arc...@amsi.com 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
-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
On Tue, May 21, 2013 at 9:23 AM, Bob Archer bob.arc...@amsi.com 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
.. 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
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
-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
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
-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
-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
On Tue, May 21, 2013 at 12:50 PM, Andrew Reedick
andrew.reed...@cbeyond.net 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
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
On Tue, May 21, 2013 at 1:13 PM, Andrew Reedick
andrew.reed...@cbeyond.net 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
-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
-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
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
-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
On Tue, May 21, 2013 at 2:27 PM, Andrew Reedick
andrew.reed...@cbeyond.net 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
-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
From: Andrew Reedick andrew.reed...@cbeyond.net
-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
On Tue, May 21, 2013 at 3:32 PM, Andrew Reedick
andrew.reed...@cbeyond.net 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
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
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
On Tue, May 21, 2013 at 4:19 PM, Daniel Shahaf d...@daniel.shahaf.name 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
Les Mikesell wrote on Tue, May 21, 2013 at 16:40:40 -0500:
On Tue, May 21, 2013 at 4:19 PM, Daniel Shahaf d...@daniel.shahaf.name
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
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:
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
On May 19, 2013, at 3:20, Zé jose.pas...@gmx.com 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.
I use
On 05/18/2013 09:16 PM, Johan Corveleyn wrote:
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
On 05/19/2013 09:33 AM, Dave Huang wrote:
I use branches in SVN all the time… you might take
Read the thread.
--
Zé
On 19.05.2013 10:51, Zé wrote:
On 05/18/2013 09:16 PM, Johan Corveleyn wrote:
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
On 05/19/2013 09:51 AM, Zé wrote:
Again, the problem is that subversion does not support branches or tags.
All it supports is basic file operations on a file system, and they
are not adequate for simulating branches or tags.
Regarding tags, there's a better way to handle them in subversion:
On 05/19/2013 10:01 AM, Branko Čibej wrote:
If Subversion
does not support your workflow, then replace Subversion, or change your
workflow.
Did you even browsed the thread? This whole thread is on how subversion
does not support branching, and how subversion would be even better than
what
On 19.05.2013 11:08, Zé wrote:
On 05/19/2013 09:51 AM, Zé wrote:
Again, the problem is that subversion does not support branches or tags.
All it supports is basic file operations on a file system, and they
are not adequate for simulating branches or tags.
Regarding tags, there's a better
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
On 19.05.2013 11:16, Zé wrote:
On 05/19/2013 10:01 AM, Branko Čibej wrote:
If Subversion
does not support your workflow, then replace Subversion, or change your
workflow.
Did you even browsed the thread? This whole thread is on how
subversion does not support branching, and how subversion
Guten Tag Zé,
am Sonntag, 19. Mai 2013 um 10:51 schrieben Sie:
7) This is the problem:
[...]
This was surely not the problem, the thread started because of
changed revision numbers, you seem to be the only who wants to remove
history of changes.
Mit freundlichen Grüßen,
Thorsten Schöning
--
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
Guten Tag Andreas Krey,
am Samstag, 18. Mai 2013 um 22:55 schrieben Sie:
All that structure is implicit. Unless someone tells you, you
have no ways to deduce which paths of a subversion repository
are meaningful to check out and which aren't.
But that's nearly the same with any other SCMs
On Sun, May 19, 2013 at 10:51 AM, Zé jose.pas...@gmx.com wrote:
On 05/18/2013 09:16 PM, Johan Corveleyn wrote:
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
On Sat, May 18, 2013 at 3:01 PM, Zé jose.pas...@gmx.com 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
On Sun, 19 May 2013 09:20:31 +, Zé wrote:
...
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
On Sat, May 18, 2013 at 1:42 PM, Zé jose.pas...@gmx.com wrote:
Besides
that, from my understanding filesystems do provide something which
could be argued as support for branches and tags because branches are
simply just work on something based on something other, which is
implemented as
On 05/13/2013 06:23 PM, Andreas Krey wrote:
No, the basic difference is that VCS operating on the whole tree can
only have branches (and thus merge info) on the whole tree either, so
you*can't* go like subversion does and map branches into the tree and
need to have them (and tags) as a separate
On 05/15/2013 04:04 PM, Les Mikesell wrote:
On Tue, May 14, 2013 at 3:33 PM, Zé jose.pas...@gmx.com wrote:
What has been said regarding
subversions lack of support for branching was, I think, quite clear.
Well, no. The only thing you've made clear is that you don't like it
or you don't
On 05/15/2013 06:59 PM, Les Mikesell wrote:
On Wed, May 15, 2013 at 12:06 PM, Andrew Reedick
andrew.reed...@cbeyond.net wrote:
Plus, telling people not use to svn's touted directory manipulation
features because of side-effects is a bit self-defeating.
Not if you want it to act like SCM's
Guten Tag Zé,
am Samstag, 18. Mai 2013 um 18:24 schrieben Sie:
The only difference between subversion and other SCM systems
is that other systems offer support for labeling and adding useful info
to those revisions, while Subversion doesn't.
Which useful info besides the name, and always
On 5/18/2013 9:37 AM, Zé wrote:
On 05/15/2013 06:59 PM, Les Mikesell wrote:
On Wed, May 15, 2013 at 12:06 PM, Andrew Reedick
andrew.reed...@cbeyond.net wrote:
Plus, telling people not use to svn's touted directory manipulation
features because of side-effects is a bit self-defeating.
Not
On Sat, May 18, 2013 at 07:33:10PM +0200, Thorsten Schöning wrote:
...
Let's put it this way: if that was actually a tag then it could also be
argued that any file system supports branching/tagging.
You ignore the versioning part of Subversion and that it guarantees
the state/history of
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,
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
On Sat, May 18, 2013 at 9:33 PM, David Chapman dcchap...@acm.org 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
On Sat, 18 May 2013 19:33:10 +, Thorsten Schöning wrote:
...
That's not an argument at all, because all one does in other SCMs is
creating branches and tags. What you really should argue is what all
devs think is common sense about branches and tags
You mean like 'I expect tags to be
On Sat, 18 May 2013 19:33:10 +, Thorsten Schöning wrote:
Guten Tag Zé,
am Samstag, 18. Mai 2013 um 18:24 schrieben Sie:
The only difference between subversion and other SCM systems
is that other systems offer support for labeling and adding useful info
to those revisions, while
On Sat, 18 May 2013 17:24:33 +, Zé wrote:
...
Compared to how other SCM systems handle tags, subversion also doesn't
have tags as a separate concept. Subversion provides a way to pinpoint
each commit objectively and unambiguously by specifying specific
revisions.
Not even that. You
On Sat, 18 May 2013 22:16:48 +, Johan Corveleyn wrote:
...
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
On Sat, May 18, 2013 at 11:15 PM, Andreas Krey a.k...@gmx.de wrote:
On Sat, 18 May 2013 22:16:48 +, Johan Corveleyn wrote:
...
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
Johan Corveleyn wrote on Sat, May 18, 2013 at 23:38:11 +0200:
On Sat, May 18, 2013 at 11:15 PM, Andreas Krey a.k...@gmx.de wrote:
The good old 'svn commit file; svn log' doesn't show the commit to
file issue?
Sorry? What issue is that?
This one is actually in the FAQ. It's inherent to
Johan Corveleyn wrote on Sat, May 18, 2013 at 23:38:11 +0200:
On Sat, May 18, 2013 at 11:15 PM, Andreas Krey a.k...@gmx.de wrote:
On Sat, 18 May 2013 22:16:48 +, Johan Corveleyn wrote:
...
Please be concrete, and give examples of what really bothers you as a
user or an admin in your
On 15.05.2013 19:06, Andrew Reedick wrote:
Isolating change is a fundamental tenet behind branching. The fact that an
outside change can affect a branch (and a tagged baseline) is wrong by
definition.
I suspect this discussion has strayed somewhat from the mandate of this
list ... so let me
On Tue, May 14, 2013 at 4:33 PM, Zé jose.pas...@gmx.com wrote:
No one is dismissing anyone's work. Quite the contrary. I don't know
I'm afriad you did, with the insistence that branching *in the form
you expect* is a given in all SCM's, and that Subversion is therefore
clearly missing a very
On Tue, May 14, 2013 at 3:33 PM, Zé jose.pas...@gmx.com wrote:
What has been said regarding
subversions lack of support for branching was, I think, quite clear.
Well, no. The only thing you've made clear is that you don't like it
or you don't understand how it is supposed to be used. You
On Wed, May 15, 2013 at 12:06 PM, Andrew Reedick
andrew.reed...@cbeyond.net wrote:
Isolating change is a fundamental tenet behind branching. The fact that an
outside change can affect a branch (and a tagged baseline) is wrong by
definition.
OK, but that means you need to anchor the
On Wed, 15 May 2013 13:06:52 +, Andrew Reedick wrote:
...
In the Future(tm), Subversion, IMHO, will need to treat branches (and tags)
as first class objects because branches and tags are core concepts of modern
version control systems.
So what? SVN decided to map them into the directory
On 05/13/2013 03:04 PM, Bob Archer wrote:
What I don't understand is why someone argues about how git does
something is better yet uses svn. Use the tool that works for you, or
works the way you expect a tool to work.
If you think my comments were about Git then you missed the point
entirely.
On 05/13/2013 04:21 PM, Bob Archer wrote:
Yes, I get what you are saying. But, to claim the way svn supports
branches and tags is a hack doesn't seem like a productive
conversation. It is far from a hack and that statement dismisses all
the hard work of design and implementation that went into
On Sat, May 11, 2013 at 10:50:12PM +0100, Zé wrote:
You're missing the point. The point is that subversion could be even
better than what it already is if it actually supported branches.
OK, I would also like Subversion to get better, so we agree here.
Now, what kinds of improvements
On 05/13/2013 10:04 AM, Bob Archer wrote:
What I don't understand is why someone argues about how git does
something is better yet uses svn. Use the tool that works for you, or
works the way you expect a tool to work.
Oh, I'm sure if we tried we could all think up plenty of reasons why someone
On Mon, May 13, 2013 at 9:04 AM, Bob Archer bob.arc...@amsi.com wrote:
What I don't understand is why someone argues about how git does something is
better yet uses svn. Use the tool that works for you, or works the way you
expect a tool to work.
Or, learn what to expect from the tool you
On 05/13/2013 10:04 AM, Bob Archer wrote:
What I don't understand is why someone argues about how git does
something is better yet uses svn. Use the tool that works for you, or
works the way you expect a tool to work.
Oh, I'm sure if we tried we could all think up plenty of reasons why
On Mon, May 13, 2013 at 03:21:15PM +, Bob Archer wrote:
I would like to see more first class support for projects and/or
defining a project root. For example, perhaps there can be an
svn:projectroot property that must be on a folder and the branch/merge
command will only work on project
On Mon, May 13, 2013 at 10:37 AM, Stefan Sperling s...@elego.de wrote:
I would like to see more first class support for projects and/or
defining a project root. For example, perhaps there can be an
svn:projectroot property that must be on a folder and the branch/merge
command will only work
On Mon, 13 May 2013 11:32:13 +, Les Mikesell wrote:
...
Maybe it is just my misconception, but I've always thought of the
difference between svn and git as being that svn conceptually tracks
complete revisions although sometimes it might generate or store
differences for some operations or
On Mon, May 13, 2013 at 12:23 PM, Andreas Krey a.k...@gmx.de wrote:
On Mon, 13 May 2013 11:32:13 +, Les Mikesell wrote:
...
Maybe it is just my misconception, but I've always thought of the
difference between svn and git as being that svn conceptually tracks
complete revisions although
On Mon, May 13, 2013 at 12:23 PM, Andreas Krey a.k...@gmx.de wrote:
On Mon, 13 May 2013 11:32:13 +, Les Mikesell wrote:
...
Maybe it is just my misconception, but I've always thought of the
difference between svn and git as being that svn conceptually tracks
complete revisions
On Mon, 13 May 2013 13:29:39 +, Les Mikesell wrote:
...
...What does git do if
you try to double-merge a change?
You can't.
Does it know about the previous
merge by its changeset commit id, look at the contents that are
already present, or just do it twice?
It doesn't have a notion
On Mon, 13 May 2013 18:35:35 +, Bob Archer wrote:
...
Been a while since I have really got into the git internals, but I think each
changeset has a SHA1 hash... if a changeset with that hash is already in a
branch merging won't do anything... there will be nothing to merge.
That said, I
On Sat, May 11, 2013 at 10:50:12PM +0100, Zé wrote:
You're missing the point. The point is that subversion could be
even better than what it already is if it actually supported
branches.
OK, I would also like Subversion to get better, so we agree here.
Now, what kinds of improvements would
On 05/09/2013 09:35 PM, Branko Čibej wrote:
The real problem here is that Subversion does not treat/renames/ as
atomic operations.
I think that the real problem here is that Subversion doesn't support
branches. The fact is that moving or copying a file or directory around
is not the
On 05/10/2013 02:56 PM, Stefan Sperling wrote:
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
On 11.05.2013 19:25, Zé wrote:
On 05/09/2013 09:35 PM, Branko Čibej wrote:
The real problem here is that Subversion does not treat/renames/ as
atomic operations.
I think that the real problem here is that Subversion doesn't support
branches. The fact is that moving or copying a file or
Guten Tag Zé,
am Samstag, 11. Mai 2013 um 19:45 schrieben Sie:
The existence of a branch shouldn't depend on whether
someone checked out an older revision or not, and creating a branch
shouldn't appear on any file's history. Essentially the people behind
all popular SCM projects understood
On Sat, May 11, 2013 at 06:45:03PM +0100, Zé wrote:
You are misrepresenting the problem. It doesn't matter if subversion
isn't like any other SCM system. The problem is that the effect of
copying, renaming or moving a file or directory around, as done by
any SCM system, is incompatible with
On 05/11/2013 08:46 PM, Stefan Sperling wrote:
On Sat, May 11, 2013 at 06:45:03PM +0100, Zé wrote:
You are misrepresenting the problem. It doesn't matter if subversion
isn't like any other SCM system. The problem is that the effect of
copying, renaming or moving a file or directory around, as
On Sat, May 11, 2013 at 1:25 PM, Zé jose.pas...@gmx.com wrote:
On 05/09/2013 09:35 PM, Branko Čibej wrote:
The real problem here is that Subversion does not treat/renames/ as
atomic operations.
I think that the real problem here is that Subversion doesn't support
branches. The fact is
On 05/11/2013 08:25 PM, Thorsten Schöning wrote:
I have a repo for binaries of one of our software which doesn't need
installation, which gets directly deployed to our customers. Each
customer is something like a branch or tag and some of the customers
are grouped for some reason, sharing the
On Sat, May 11, 2013 at 1:45 PM, Zé jose.pas...@gmx.com wrote:
You are misrepresenting the problem. It doesn't matter if subversion isn't
like any other SCM system. The problem is that the effect of copying,
renaming or moving a file or directory around, as done by any SCM system, is
On Sat, May 11, 2013 at 3:25 PM, Thorsten Schöning
tschoen...@am-soft.de wrote:
I have only little experience with git almost a year ago, but what I
remember is that git does support tags and branches and neither of
those could be structured in any way, git only allowed one level for
tags
Guten Tag Zé,
am Samstag, 11. Mai 2013 um 23:26 schrieben Sie:
That's not exactly a development branch, but a directory tree.
That's simply a matter of taste and what I said for customer/server
related hierarchies of tags fits perfectly well for branches which
develop towards e.g. one bigger
-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
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
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
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
-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
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,
-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 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
-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
1 - 100 of 102 matches
Mail list logo
