Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » U++ Developers corner » SVN plan...
Re: SVN plan... [message #12655 is a reply to message #12645] Mon, 12 November 2007 14:14 Go to previous messageGo to previous message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
mr_ped wrote on Mon, 12 November 2007 09:12

Quote:

It would also be interesting the possibility to 'go back' to an older revision locking the repository in order to avoid unwanted updates during regression tests and, maybe, the ability to check out an arbitrary revision on a different local path, for tests purposes.


Why locking out updates, if you work with revision numbers? During tests?


I'll make an example: suppose you're in revision 50, you want to see what happened to 49... so you request the 49 one.
Now, you go to drink a coffee, you return to PC, forgetting you did request 49 version and start working on your files... you update SVN and you get a 51 version that is a modified 49 one, not 50... Ok, that's solvable, but not nice thing.
That I wanted to say speaking about locking. Here you could :
1- Put IDE in read only mode, if you're looking in a previous fetched revision (a bit drastic way, but it works...)
2- When you save files, IDE should tell you that you're doing it on a past revision
3- Fetch past revision in a separate tree.
The 1 is the fastest, the 2 is half a way between speed and security and the 3d is slow but most secure.

Quote:


Thinking about local test of different revision...

As the include paths within packages are relative to nests, this sounds a bit cumbersome inside TheIDE right now.
You can't use different package name, that would break include paths in sources.
I wonder what would happen if one would have two packages with same name in two different nests. Probably some havoc.


With theide I usually keep 1 source tree for the stable one in
~/sources/upp, and another one in ~/sources/uppdev with current uvs tree. I use the upp one to compile the uppdev, adding a nest to the uppdev tree in the upp nests. So, I *do* have many packages with same names on different nests, and that makes no problem at all... The important thing is that nests must not overlap. I've got an 'uppsrc' nest with stable ide, and an 'uppdev' nest with devel one pointing to different stuffs. Of course, you can't mix both !

Quote:


It looks to me like the least problematic way to go is to "clone" your current nests, disable the original ones, check out older revisions into cloned nests, rebuild all, test.
Possible to do by hand with TheIDE already now, but some additional support to clone/enable/disable nests would be maybe nice.


That's my 3rd point above.... doew work, but it's slow !
IMHO the best would be fetch past revision in current tree AND provide some locking mechanics to avoid editing of files when an older revision is fetched in.
Just another example : you're working on rev. 50, you find a bug. You fetch past revisions, doing a binary search, and you find that the bug appears between 44 and 45. You do it recompiling each time, but it should be fast enough, as only few files change. So, you find the bug, ask theide to create a diff between buggy and non buggy code, revert to latest version and apply the patch, or correct manually the code.
That could work on separate trees, but would be awfully slow...

Quote:


But I think it should be either as complete as possible to make it almost something like "single" click experience, or there's no point to adding anything and current status will do. Going only half way will not make happy less experienced users, and the more advanced users will save only couple of second or minutes, so I think it would not really improve the current situation.


I agree. IMHO, that should be a single click to "update svn" that takes care of file adding/removing/changes on svn repo, and the same for going back. And it should be limited to files managet from theide, so listed in UPP files.
Having a locally synchronized svn repo could be a plus.

Ciao

Max
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Quick and dirty solution to .icpp problem...
Next Topic: About DHCtrl and window handles...
Goto Forum:
  


Current Time: Sat May 11 10:08:18 CEST 2024

Total time taken to generate the page: 0.01511 seconds