RE: Suggestion: Transparent Branching
> -Original Message- > From: Branko Čibej [mailto:br...@xbc.nu] > Sent: Thursday, July 29, 2010 10:05 AM > To: dev@subversion.apache.org > Subject: Re: Suggestion: Transparent Branching > > On 07.07.2010 18:29, Greg Hudson wrote: > > On Wed, 2010-07-07 at 11:44 -0400, Marco Jansen wrote: > > > >> So therefor, what we would like to see is to be able to have a > transparent > >> branch: One which fetches updates from both branch and trunk, without > having > >> them listed as changes or triggering commits. In essence it's reading > from > >> two branches, where a last known revision of a file could be from either > >> branch, and committing to one only when it has changes from this 'either' > >> latest revision. > >> > > I'm not sure if this is a feature of any popular version control system. > > What would happen if trunk changes didn't merge easily with the changes > > on one or more transparent branches? > > > > ClearCase and AccuRev come to mind. AccuRev might not be that popular, > but ClearCase definitely is. > Ahh, I think you refer to "Pass-through streams", where an individual file is branched and changes to that file occur on the branch, but changes to all other files occur on the trunk where the branch was initially created. It’s a powerful idea (especially when you come to work with partial inclusion or exclusion filters) but requires a powerful view to keep track of what you're changing and a good system for keeping track of a branch's parent(s). Eg. I have a directory structure like: /Framework and /Framework/Plugin. I branch the plugin directory so I can work on that, but I still see the full directory structure. If I make changes to anything in the Framework directory, it occurs on that branch that is shared by all. If I make a change in the Plugin directory, only I see the change until I merge it back. I think it's possible SVN could manage this with a 'redirect' property that sends any commit/update operations to a specified revision. So you still branch as usual, but any operation on a directory would be made to apply to a directory elsewhere in the repo.
Re: Suggestion: Transparent Branching
On 07.07.2010 18:29, Greg Hudson wrote: > On Wed, 2010-07-07 at 11:44 -0400, Marco Jansen wrote: > >> So therefor, what we would like to see is to be able to have a transparent >> branch: One which fetches updates from both branch and trunk, without having >> them listed as changes or triggering commits. In essence it's reading from >> two branches, where a last known revision of a file could be from either >> branch, and committing to one only when it has changes from this 'either' >> latest revision. >> > I'm not sure if this is a feature of any popular version control system. > What would happen if trunk changes didn't merge easily with the changes > on one or more transparent branches? > ClearCase and AccuRev come to mind. AccuRev might not be that popular, but ClearCase definitely is. -- Brane
RE: Suggestion: Transparent Branching
> -Original Message- > From: Marco Jansen [mailto:sart...@gmail.com] > Sent: Wednesday, July 07, 2010 4:44 PM > To: dev@subversion.apache.org > Subject: Suggestion: Transparent Branching > > Greetings, > > The issue we have is that we use trunk as a stable version, but with ongoing > maintenance. Quick bug fixes to improve stability are generally directly > committed to trunk, and sometimes even rapidly deployed from trunk. > Surely you just want to merge only the revisions that were changed on the branch, not those that were merged from trunk. Doesn't mergeinfo help you here? If not, if you marked each revision that was merged, wouldn't that allow you to skip those when merging back to trunk? > Extended changes, often longer-term projects, are supposed to go in > branches. The biggest problem is that these branches do not automatically > receive the maintenance and fixes committed to trunk. Ofcourse, there is a > known work-around for this: Merging trunk into the branch; and this could > even be automated with a script-hook. It still poses a problem that this > merge is considered a change from the branch's viewpoint, and therefor gets > committed on its own in a seperate revision in the branch once more, while > all it is is an update from trunk. This often complicates the final merge > from branch back to trunk, since the changes have been committed in both. > I do like the idea of 'automatic' merges to multiple destinations. So I would branch 2 times from trunk, then I could make a change to trunk and have that change cascade onto both branches (ie without performing 2 separate merges). That'd be pretty cool, though I don't know if it's possible or really desirable :) > So therefor, what we would like to see is to be able to have a transparent > branch: One which fetches updates from both branch and trunk, without having > them listed as changes or triggering commits. In essence it's reading from > two branches, where a last known revision of a file could be from either > branch, and committing to one only when it has changes from this 'either' > latest revision. > Sounds like a bodge of a suggestion - you want a view of the repo where 2 branches are seen as 1, the latest revision from either is used? So if trunk was updated, it would suddenly take precedence and obscure the same file on the branch. That sounds like a good way to screw whatever it is you're working on, as your WC could change at any time - all those changes you made to branch suddenly disappeared and you see the file from trunk. Not good, and confusing as hell.
Re: Suggestion: Transparent Branching
Hello Marco, On Wednesday 07 July 2010, Marco Jansen wrote: > So therefor, what we would like to see is to be able to have a > transparent branch: One which fetches updates from both branch and > trunk, without having them listed as changes or triggering commits. In > essence it's reading from two branches, where a last known revision of a > file could be from either branch, and committing to one only when it has > changes from this 'either' latest revision. FSVS (fsvs.tigris.org) is not a source control system per se, but more of a filesystem versioning system (like for /usr, /etc, or /). But: FSVS allows to "overlay" multiple repository URLs, and the "topmost" entry is visible in the working copy. See here for some more details: http://doc.fsvs-software.org/doxygen-gif/group__howto__master__local.html So the base checkout would be trunk, with an initially empty branch on top of that. As files get changed they get committed to the branch; updates from trunk would get through, though. I'm afraid that this won't fit your bill completely, but if the project is big enough and the changes sparse enough so that no single file gets changed on both trunk and branch (or at least so infrequently that it could be merged manually) it might just work for you. You're welcome to try it; the main site is http://fsvs.tigris.org, and some distributions already have packages available. I'd be happy to hear about any feedback, ideas, and experiences; please share them on FSVS' users mailing list. Regards, Phil
Re: Suggestion: Transparent Branching
On Wed, 2010-07-07 at 11:44 -0400, Marco Jansen wrote: > So therefor, what we would like to see is to be able to have a transparent > branch: One which fetches updates from both branch and trunk, without having > them listed as changes or triggering commits. In essence it's reading from > two branches, where a last known revision of a file could be from either > branch, and committing to one only when it has changes from this 'either' > latest revision. I'm not sure if this is a feature of any popular version control system. What would happen if trunk changes didn't merge easily with the changes on one or more transparent branches?
Suggestion: Transparent Branching
Greetings, In the years I've been using SVN as a developer in a rather dynamic development team, we've found one 'gap' we consider in SVN. The intention of this mail is to figure out whether this first of all is indeed a gap, a known gap and perhaps even planned feature, or actually implemented but overlooked by us. Should the requested feature not be implemented nor planned yet, then I'm willing to consider working on it myself as a future contribution. The issue we have is that we use trunk as a stable version, but with ongoing maintenance. Quick bug fixes to improve stability are generally directly committed to trunk, and sometimes even rapidly deployed from trunk. Extended changes, often longer-term projects, are supposed to go in branches. The biggest problem is that these branches do not automatically receive the maintenance and fixes committed to trunk. Ofcourse, there is a known work-around for this: Merging trunk into the branch; and this could even be automated with a script-hook. It still poses a problem that this merge is considered a change from the branch's viewpoint, and therefor gets committed on its own in a seperate revision in the branch once more, while all it is is an update from trunk. This often complicates the final merge from branch back to trunk, since the changes have been committed in both. So therefor, what we would like to see is to be able to have a transparent branch: One which fetches updates from both branch and trunk, without having them listed as changes or triggering commits. In essence it's reading from two branches, where a last known revision of a file could be from either branch, and committing to one only when it has changes from this 'either' latest revision. If it is a current feature, I'ld be happy to learn how. If it isn't, I'ld happy to dig in and contribute to make it possible. I'm looking forward to comments, Marco Jansen