Re: svn merge - get the last revision of a file(s)
On Friday 01 July 2011, Rui Gonçalves wrote: > Like I said before, I'm currently using the subclise plugin to manage > all the svn interaction with the repository. > > As far as I know, I'm able to select the revisions which I want to > apply but I'm not sure about the following aspect: > - on revision 10, aaa.php has some changes > - on revision 15, aaa.php has other changes This is perfectly normal, sometimes a file is changed multiple times for a single feature. In order to merge the feature branch back into trunk, you just merge those changes, either in a single step or one after the other. > Once on subclipse is not handy to select latest revision of a certain > file (15, considering my example), is there any way to obtain that > information. The first part of this sentence doesn't make sense to me, it looks like broken English. Concerning how to get at the 15, you can just go through each file in your branch and check when they were last changed using "svn log", but that is unnecessarily complicated. Just look at the log of the branch as a whole in order to decide which changes to merge. BTW: I have the feeling as if you wanted to replace the version of a file in trunk with the version in the branch. This of course can be done, just use "svn copy", but it is a bad approach to branching and merging. The reason is that if trunk was changed, the changes there are effectively discarded. Still, I'm not really sure I understand what you are trying to achieve. Really, giving an example would help, all with what you have, what you do, and what you expect to have afterwards. This still isn't clear. Good luck! Uli ** Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 ** Visit our website at http://www.dominolaser.com ** Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden. E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich. **
Re: RPM packaging components in trunk out of date and dangerous
On Sun, Jul 3, 2011 at 1:20 PM, Stefan Sperling wrote: > On Sat, Jul 02, 2011 at 10:39:01AM -0400, Nico Kadel-Garcia wrote: >> I'm happy to submit these as distinct issues for the issue tracker, >> but in the short therm, pulling out the unusable rhel-3 and rhel-4 >> packaging would be a good start. > > Feel free to file these issues so this doesn't fall through the cracks. > Thanks! > > Not sure yet, but I suppose we'll end up deleting the RPM packaging > from our tree since it is not being maintained. > As you mentioned better maintained packages exist elsewhere. For what it's worth, this isn't the first complaint I've heard about the spec files we "maintain" in our tree. In our defense, we do remove the packages/ directory from the shipped tarballs, so it takes an industrious user to actually find and use the spec files. But it appears that the status quo is still causing problems, so fixes would be appreciated (or we can just nuke 'em from the repo). -Hyrum
Re: RPM packaging components in trunk out of date and dangerous
On Mon, Jul 04, 2011 at 09:29:56AM -0500, Hyrum K Wright wrote: > For what it's worth, this isn't the first complaint I've heard about > the spec files we "maintain" in our tree. That is because Nico keeps bringing it up :) > In our defense, we do > remove the packages/ directory from the shipped tarballs, so it takes > an industrious user to actually find and use the spec files. But it > appears that the status quo is still causing problems, so fixes would > be appreciated (or we can just nuke 'em from the repo). I'd say we nuke them now and bring them back as soon as someone steps up to maintain them again.
Re: RPM packaging components in trunk out of date and dangerous
On Mon, Jul 4, 2011 at 10:50 AM, Stefan Sperling wrote: > On Mon, Jul 04, 2011 at 09:29:56AM -0500, Hyrum K Wright wrote: >> For what it's worth, this isn't the first complaint I've heard about >> the spec files we "maintain" in our tree. > > That is because Nico keeps bringing it up :) It's been quite a while. With 1.7 in alpha testing and RHEL 6 in production, it seemed a good time to do so. >> In our defense, we do >> remove the packages/ directory from the shipped tarballs, so it takes >> an industrious user to actually find and use the spec files. But it >> appears that the status quo is still causing problems, so fixes would >> be appreciated (or we can just nuke 'em from the repo). > > I'd say we nuke them now and bring them back as soon as someone > steps up to maintain them again. Nuke from orbit. A "README" with a pointer to RPMforge "extras" and to Fedora would make sense. I'm trying to submit an issue to the issue tracker. Turns out there's an old account there called "nkadel", but it's not tied to "nka...@gmail.com". It's probably my ancient nka...@comcast.net account. I've set up a new one as "nkadelgarcia", as the easiest workaround, so I'll drop in notes there.
Re: RPM packaging components in trunk out of date and dangerous
On Mon, Jul 4, 2011 at 9:50 AM, Stefan Sperling wrote: > On Mon, Jul 04, 2011 at 09:29:56AM -0500, Hyrum K Wright wrote: >> For what it's worth, this isn't the first complaint I've heard about >> the spec files we "maintain" in our tree. > > That is because Nico keeps bringing it up :) Actually, no. I've heard this complaint from *other* people, not just Nico. :) -Hyrum
