Search Results

Search found 783 results on 32 pages for 'branches'.

Page 8/32 | < Previous Page | 4 5 6 7 8 9 10 11 12 13 14 15  | Next Page >

  • Suggest the best options to me to design the dynamic web interface using PHP MYSQL and AJAX

    - by Krishna
    Hello, I am designing a web interface for a company. I am describing the company's profile: company is currently having 5 branches and planning to extend their branches all over the country. it is an insurance surveying company. they are dealing with 6 Categories in the insurance domain, vide .. Engineering Fire Marine Motor Miscellaneous Risk Inspection and branches named as b1, b2, b3, b4, b5 and Extending. and finally they have contract with 22 companies. For each claim they are assign a unique ID. like contractcompany/category/serialno Ex: take a contracted company names as xxx, sss, zzz. xxx/Engineering/001 sss/Engineering/001 . . . xxx/Enginnering/002 sss/Engineering/002 . . . xxx/Fire/001 sss/Fire/001 . . . xxx/Fire/002 . . . xxx/Fire/002 . . . and so on..... by this way they issue the unique ID for each claim. Finally what i want is developing the interface with PHP mysql and ajax auto generating the unique id for each claim. store full details of the claims with reference to unique id. show all claims in one page, and they can view by branch wise and category wise. send monthly Report (All claims they have given and status of claims) to contract companies. give access to contracted companies, but they can view only their respective claims. Each claim has its own documents. So they can be uploaded by own company users or administrator. these files are associated with unique ID. contracted companies can view files. Give access to branches to enter new claims and update old claims. Administrator can create, update and delete all the claims and their details. Only administrator can grant new users (own company branches / contracted companies) Finally the the panel is completely database driven. Could any body can help. Thanks in advance Kindly do the needful and oblige Thanks and Regards Krishna. P [email protected]

    Read the article

  • Creating multiple heads in remote repository

    - by Jab
    We are looking to move our team (~10 developers) from SVN to mercurial. We are trying to figure out how to manage our workflow. In particular, we are trying to see if creating remote heads is the right solution. We currently have a very large repository with multiple, related projects. They share a lot of code, but pieces of the project are deployed by different teams (3 teams) independent of other portions of the code-base. So each team is working on concurrent large features. The way we currently handles this in SVN are branches. Team1 has a branch for Feature1, same deal for the other teams. When Team1 finishes their change, it gets merged into the trunk and deployed out. The other teams follow suite when their project is complete, merging of course. So my initial thought are using Named Branches for these situations. Team1 makes a Feature1 branch off of the default branch in Hg. Now, here is the question. Should the team PUSH that branch, in it's current/half-state to the repository. This will create a second head in the core repo. My initial reaction was "NO!" as it seems like a bad idea. Handling multiple heads on our repository just sounds awful, but there are some advantages... First, the teams want to setup Continuous Integration to build this branch during their development cycle(months long). This will only work if the CI can pull this branch from the repo. This is something we do now with SVN, copy a CI build and change the branch. Easy. Second, it makes it easier for any team member to jump onto the branch and start working. Without pushing to the core repo, they would have to receive a push from a developer on that team with the changeset information. It is also possible to lose local commits to hardware failure. The chances increase a lot if it's a branch by a single developer who has followed the "don't push until finished" approach. And lastly is just for ease of use. The developers can easily just commit and push on their branch at any time without consequence(as they do today, in their SVN branches). Is there a better way to handle this scenario that I may be missing? I just want a veteran's opinion before moving forward with the strategy. For bug fixes we like the general workflow of mecurial, anonymous branches that only consist of 1-2 commits. The simplicity is great for those cases. By the way, I've read this , great article which seems to favor Named branches.

    Read the article

  • Remove Item From Object SubList (LINQ)

    - by X3074861X
    I have an object that looks like this : public class Consortium { public string Id { get; set; } [JsonConverter(typeof(EnumDescriptionConverter))] public SourceType Type { get; set; } public List<UserLibrary> Branches { get; set; } } Each Consortium has a list of UserLibrary's associated with it, and that class looks like this : public class UserLibrary { public string LibraryId { get; set; } public string RetailerId {get; set;} public string UserId { get; set; } public string Name { get; set; } public DateTime CreatedAt { get; set; } } I have a method which will allow the user to remove a library from one of their consortium (note: There may be many branches associated to the consortium). However, I'm only being supplied a LibraryId, so I'm forced to traverse their list of Consortium, find which one contains the given id, then iterate over the branches and remove the one that matches the id. Here is how I'm currently accomplishing this : // Get the current list of consortiums var user = _mediator.Send(new GetUserProfileCommand { UserProfileId = _principle.UserProfileId }); var userConsortia = user.SavedConsortia; // the consortium to remove the library from var branchToRemove = _libraryService.GetLibrary(id); var consortRemove = new UserConsortium(); foreach (var userConsortium in userConsortia) { if (userConsortium.Branches.FirstOrDefault(c => string.Equals(c.LibraryId, id, StringComparison.OrdinalIgnoreCase)) != null) { consortRemove = userConsortium; } } // if the consortium id is null, something is f* if (consortRemove.Id == null) { return new JsonDotNetResult(HttpStatusCode.BadRequest); } // first remove the consortia userConsortia.Remove(consortRemove); // remove the branch from the consortium consortRemove.Branches.RemoveAll(ul => string.Equals(ul.LibraryId, id, StringComparison.OrdinalIgnoreCase)); // add it back in without the branch userConsortia.Add(consortRemove); Question : Is there a LINQ expression I'm missing here that can help me consolidate this logic, or is there a better way of doing this?

    Read the article

  • git branch naming best practices

    - by skiphoppy
    I've been using a local git repository interacting with my group's CVS repository for several months, now. I've made an almost neurotic number of branches, most of which have thankfully merged back into my trunk. But naming is starting to become an issue. If I have a task easily named with a simple label, but I accomplish it in three stages which each include their own branch and merge situation, then I can repeat the branch name each time, but that makes the history a little confusing. If I get more specific in the names, with a separate description for each stage, then the branch names start to get long and unwieldy. I did learn looking through old threads here that I could start naming branches with a / in the name, i.e., topic/task, or something like that. I may start doing that and seeing if it helps keep things better organized. What are some best practices for naming git branches? Edit: Nobody has actually suggested any naming conventions. I do delete branches when I'm done with them. I just happen to have several around due to management constantly adjusting my priorities. :) As an example of why I might need more than one branch on a task, suppose I need to commit the first discrete milestone in the task to the group's CVS repository. At that point, due to my imperfect interaction with CVS, I would perform that commit and then kill that branch. (I've seen too much weirdness interacting with CVS if I try to continue to use the same branch at that point.)

    Read the article

  • Git-svn refuses to create branch on svn repository error: "not in the same repository"

    - by Danny
    I am attempting to create a svn branch using git-svn. The repository was created with --stdlayout. Unfortunately it generates an error stating the "Source and dest appear not to be in the same repository". The error appears to be the result of it not including the username in the source url. $ git svn branch foo-as-bar -m "Attempt to make Foo into Bar." Copying svn+ssh://my.foo.company/r/sandbox/foo/trunk at r1173 to svn+ssh://[email protected]/r/sandbox/foo/branches/foo-as-bar... Trying to use an unsupported feature: Source and dest appear not to be in the same repository (src: 'svn+ssh://my.foo.company/r/sandbox/foo/trunk'; dst: 'svn+ssh://[email protected]/r/sandbox/foo/branches/foo-as-bar') at /home/me/.install/git/libexec/git-core/git-svn line 610 I intially thought this was simply a configuration issue, examination of .git/config doesn't suggest anything incorrect. [svn-remote "svn"] url = svn+ssh://[email protected]/r fetch = sandbox/foo/trunk:refs/remotes/trunk branches = sandbox/foo/branches/*:refs/remotes/* tags = sandbox/foo/tags/*:refs/remotes/tags/* I am using git version 1.6.3.3. Can anyone shed any light on why this might be occuring, and how best to address it?

    Read the article

  • Subversion svn:externals - What's wrong here?

    - by Brandon Montgomery
    I first want to say I've read the Subversion manual. I've read this question. I've also read this question. Here's my dilemma. Let's say I have 3 repositories laid out like this: DataAccessObject/ branches/ tags/ trunk/ DataAccessObject/ DataAccessObjectTests/ PlanObject/ branches/ tags/ trunk/ PlanObject/ PlanObjectTests/ WinFormsPlanViewer/ branches/ tags/ trunk/ WinFormsPlanViewer/ The PlanObject and DataAccessObject repositories contain shared projects. They are used by the WinFormsPlanViewer, but also by several other projects in several other repositories. Bear with me here. I put an svn:externals definition on the WinFormsPlanViewer/trunk folder like this: https://server/svn/PlanObject/trunk Objects https://server/svn/DataAccessObject/trunk Objects And here's what I see after I do an svn update. WinFormsPlanViewer/ branches/ tags/ trunk/ WinFormsPlanViewer/ Objects/ DataAccessObject/ DataAccessObjectTests/ The PlanObject stuff doesn't even come down in the update! I don't know if this has anything to do with it, but there's an externals definition on the PlanObject/trunk folder also: https://server/svn/DataAccessObject/trunk Objects What's going on here? What am I doing wrong? Are there bad consequences of referencing the PlanObject and the DataAccessObject from the WinFormsPlanViewer using svn:externals when the PlanObject references the DataAccessObject using svn:externals also?

    Read the article

  • Using git-svn with slightly strange svn layout

    - by Ibrahim
    Hi guys, I'm doing an internship and they are using SVN (although there has been some discussion of moving to hg or git but that's not in the immediate future). I like git so I would like to use git-svn to interact with the svn repository and be able to do local commits and branches and stuff like that (rebasing before committing to svn of course). However, there is one slight wrinkle, the svn repository layout is a little weird. It basically looks like this /FOO +-branches +-tags +-trunk +-FOO +-myproject Basically, my project has been stuck into a subdirectory of trunk, and there is another project that is also a subdirectory of the trunk. If I use git-svn and only clone the directory for my project instead of the root, will it get confused or cause any problems? I just wonder because the commit numbers are incremented for the entire repository and not just my project, so would commits be off or anything like that? I probably wouldn't push any branches or tags to SVN because I'd prefer to just do those locally in git and I don't know how git-svn deals with branches and tags anyway, and no one else uses them so I find little point in doing so. Thanks for the help!

    Read the article

  • svn dev cycle. howto lots minor "features" pending for approval.

    - by Julian Davchev
    Hi I've read similar questions regarding that but still feel the need to ask a question. I have scenario where we have lots of tiny "features" pending for approval. I generally see two approaches. 1.Keep trunk solid and have tons of branches for each tiny "feature". Basically every new thingy is a branch. Cons: - Might become nightmare to support so many branches no matter how small a change. Keeping all branches in sync etc etc. - Worst con I see in this is setup of test system so one can easily examine changes to approve (basically need to support all branches which seems insane). Pros: - Seemningly easy once approved a branch to be merged back to trunk and new release to be tagged and deployed. 2.For big features a branch is released and for small changes all goes in trunk(relatively stable) directly. Pros: - Easier to set test system as most of the time all will be directly visible. For big features should be easy to maintain separate branch on test. Cons: - Don't really see how release will go. I will not be able to basically release one part of trunk This would involve cherrypicking which is crazy to follow. Other approach is I just enforce that after some time (a week or so) all small features need to be approved so they can deployed before giving new tasks. I just create release branch and either all or none of small features are going live. This will be some fun discussion with head people. I guess having lots of small pending stuff is very problematic to follow technically.

    Read the article

  • Using SVN post-commit hook to update only files that have been commited

    - by fondie
    I am using an SVN repository for my web development work. I have a development site set up which holds a checkout of the repository. I have set up an SVN post-commit hook so that whenever a commit is made to the repository the development site is updated: cd /home/www/dev_ssl /usr/bin/svn up This works fine but due to the size of the repository the updates take a long time (approx. 3 minutes) which is rather frustrating when making regular commits. What I'd like is to change the post-commit hook to only update those files/directories that have been committed but I don't know how to go about doing this. Updating the "lowest common directory" would probably be the best solution, e.g. If committing the follow files: /branches/feature_x/images/logo.jpg /branches/feature_x/css/screen.css It would update the directory: /branches/feature_x/ Can anyone help me create a solution that achieves this please? Thanks! Update: The repository and development site are located on the same server so network issues shouldn't be involved. CPU usage is very low, and I/O should be ok (it's running on hi-spec dedicated server) The development site is approx. 7.5GB in size and contains approx. 600,000 items, this is mainly due to having multiple branches/tags

    Read the article

  • Using git svn with some awkward permissions

    - by Migs
    Due to some funky permissions on our client's side that we can't change, we have a project whose hierarchy looks something like: projectname/trunk: foo/, bar/, baz/ projectname/branches: branch1/, branch2/ (where branch1 and branch2 each contain foo, bar, and baz.) The thing is, I have no permission to access trunk, so I can't just do a clone of project/trunk. I do have permission to access branches. What I am currently doing is checking out each subdirectory individually via git svn clone, so that each one has their own git repo. I use a script to update/commit them all, but what I would prefer to do is to check them all out under a single repo, and be able to commit changes with a single call to git svn dcommit. Is this possible? I mentioned the branches hierarchy because if possible, I'd also like to be able to track the branches the way I could if the permissions were more sane. I've tried permuting a lot of options that sounded useful, but I haven't found one that gives me exactly what I want. I sense that the solution may have something to do with --no-minimize-url, but I'm not even sure about that, as it didn't help me when I tried it.

    Read the article

  • How I do VCS

    - by Wes McClure
    After years of dabbling with different version control systems and techniques, I wanted to share some of what I like and dislike in a few blog posts.  To start this out, I want to talk about how I use VCS in a team environment.  These come in a series of tips or best practices that I try to follow.  Note: This list is subject to change in the future. Always use some form of version control for all aspects of software development. Development is an evolution.  Looking back at where we were is an invaluable asset in that process.  This includes data schemas and documentation. Reverting / reapplying changes is absolutely critical for efficient development. The tools I use: Code: Hg (preferred), SVN Database: TSqlMigrations Documents: Sometimes in code repository, also SharePoint with versioning Always tag a commit (changeset) with comments This is a quick way to describe to someone else (or your future self) what the changeset entails. Be brief but courteous. One or two sentences about the task, not the actual changes. Use precommit hooks or setup the central repository to reject changes without comments. Link changesets to documentation If your project management system integrates with version control, or has a way to externally reference stories, tasks etc then leave a reference in the commit.  This helps locate more information about the commit and/or related changesets. It’s best to have a precommit hook or system that requires this information, otherwise it’s easy to forget. Ability to work offline is required, including commits and history Yes this requires a DVCS locally but doesn’t require the central repository to be a DVCS.  I prefer to use either Git or Hg but if it isn’t possible to migrate the central repository, it’s still possible for a developer to push / pull changes to that repository from a local Hg or Git repository. Never lock resources (files) in a central repository… Rude! We have merge tools for a reason, merging sucked a long time ago, it doesn’t anymore… stop locking files! This is unproductive, rude and annoying to other team members. Always review everything in your commit. Never ever commit a set of files without reviewing the changes in each. Never add a file without asking yourself, deep down inside, does this belong? If you leave to make changes during a review, start the review over when you come back.  Never assume you didn’t touch a file, double check. This is another reason why you want to avoid large, infrequent commits. Requirements for tools Quickly show pending changes for the entire repository. Default action for a resource with pending changes is a diff. Pluggable diff & merge tool Produce a unified diff or a diff of all changes.  This is helpful to bulk review changes instead of opening each file. The central repository is not your own personal dump yard.  Breaking this rule is a sure fire way to get the F bomb dropped in front of your name, multiple times. If you turn on Visual Studio’s commit on closing studio option, I will personally break your fingers. By the way, the person(s) in charge of this feature should be fired and never be allowed near programming, ever again. Commit (integrate) to the central repository / branch frequently I try to do this before leaving each day, especially without a DVCS.  One never knows when they might need to work from remote the following day. Never commit commented out code If it isn’t needed anymore, delete it! If you aren’t sure if it might be useful in the future, delete it! This is why we have history. If you don’t know why it’s commented out, figure it out and then either uncomment it or delete it. Don’t commit build artifacts, user preferences and temporary files. Build artifacts do not belong in VCS, everything in them is present in the code. (ie: bin\*, obj\*, *.dll, *.exe) User preferences are your settings, stop overriding my preferences files! (ie: *.suo and *.user files) Most tools allow you to ignore certain files and Hg/Git allow you to version this as an ignore file.  Set this up as a first step when creating a new repository! Be polite when merging unresolved conflicts. Count to 10, cuss, grab a stress ball and realize it’s not a big deal.  Actually, it’s an opportunity to let you know that someone else is working in the same area and you might want to communicate with them. Following the other rules, especially committing frequently, will reduce the likelihood of this. Suck it up, we all have to deal with this unintended consequence at times.  Just be careful and GET FAMILIAR with your merge tool.  It’s really not as scary as you think.  I personally prefer KDiff3 as its merging capabilities rock. Don’t blindly merge and then blindly commit your changes, this is rude and unprofessional.  Make sure you understand why the conflict occurred and which parts of the code you want to keep.  Apply scrutiny when you commit a manual merge: review the diff! Make sure you test the changes (build and run automated tests) Become intimate with your version control system and the tools you use with it. Avoid trial and error as much as is possible, sit down and test the tool out, read some tutorials etc.  Create test repositories and walk through common scenarios. Find the most efficient way to do your work.  These tools will be used repetitively, so inefficiencies will add up. Sometimes this involves a mix of tools, both GUI and CLI. I like a combination of both Tortoise Hg and hg cli to get the job efficiently. Always tag releases Create a way to find a given release, whether this be in comments or an explicit tag / branch.  This should be readily discoverable. Create release branches to patch bugs and then merge the changes back to other development branch(es). If using feature branches, strive for periodic integrations. Feature branches often cause forked code that becomes irreconcilable.  Strive to re-integrate somewhat frequently with the branch this code will ultimately be merged into.  This will avoid merge conflicts in the future. Feature branches are best when they are mutually exclusive of active development in other branches. Use and abuse local commits , at least one per task in a story. This builds a trail of changes in your local repository that can be pushed to a central repository when the story is complete. Never commit a broken build or failing tests to the central repository. It’s ok for a local commit to break the build and/or tests.  In fact, I encourage this if it helps group the changes more logically.  This is one of the main reasons I got excited about DVCS, when I wanted more than one changeset for a set of pending changes but some files could be grouped into both changesets (like solution file / project file changes). If you have more than a dozen outstanding changed resources, there should probably be more than one commit involved. Exceptions when maintaining code bases that require shotgun surgery, in this case, it’s a design smell :) Don’t version sensitive information Especially usernames / passwords   There is one area I haven’t found a solution I like yet: versioning 3rd party libraries and/or code.  I really dislike keeping any assemblies in the repository, but seems to be a common practice for external libraries.  Please feel free to share your ideas about this below.    -Wes

    Read the article

  • T4 Performance Counters explained

    - by user13346607
    Now that T4 is out for a few month some people might have wondered what details of the new pipeline you can monitor. A "cpustat -h" lists a lot of events that can be monitored, and only very few are self-explanatory. I will try to give some insight on all of them, some of these "PIC events" require an in-depth knowledge of T4 pipeline. Over time I will try to explain these, for the time being these events should simply be ignored. (Side note: some counters changed from tape-out 1.1 (*only* used in the T4 beta program) to tape-out 1.2 (used in the systems shipping today) The table only lists the tape-out 1.2 counters) 0 0 1 1058 6033 Oracle Microelectronics 50 14 7077 14.0 Normal 0 false false false EN-US JA X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin;} pic name (cpustat) Prose Comment Sel-pipe-drain-cycles, Sel-0-[wait|ready], Sel-[1,2] Sel-0-wait counts cycles a strand waits to be selected. Some reasons can be counted in detail; these are: Sel-0-ready: Cycles a strand was ready but not selected, that can signal pipeline oversubscription Sel-1: Cycles only one instruction or µop was selected Sel-2: Cycles two instructions or µops were selected Sel-pipe-drain-cycles: cf. PRM footnote 8 to table 10.2 Pick-any, Pick-[0|1|2|3] Cycles one, two, three, no or at least one instruction or µop is picked Instr_FGU_crypto Number of FGU or crypto instructions executed on that vcpu Instr_ld dto. for load Instr_st dto. for store SPR_ring_ops dto. for SPR ring ops Instr_other dto. for all other instructions not listed above, PRM footnote 7 to table 10.2 lists the instructions Instr_all total number of instructions executed on that vcpu Sw_count_intr Nr of S/W count instructions on that vcpu (sethi %hi(fc000),%g0 (whatever that is))  Atomics nr of atomic ops, which are LDSTUB/a, CASA/XA, and SWAP/A SW_prefetch Nr of PREFETCH or PREFETCHA instructions Block_ld_st Block loads or store on that vcpu IC_miss_nospec, IC_miss_[L2_or_L3|local|remote]\ _hit_nospec Various I$ misses, distinguished by where they hit. All of these count per thread, but only primary events: T4 counts only the first occurence of an I$ miss on a core for a certain instruction. If one strand misses in I$ this miss is counted, but if a second strand on the same core misses while the first miss is being resolved, that second miss is not counted This flavour of I$ misses counts only misses that are caused by instruction that really commit (note the "_nospec") BTC_miss Branch target cache miss ITLB_miss ITLB misses (synchronously counted) ITLB_miss_asynch dto. but asynchronously [I|D]TLB_fill_\ [8KB|64KB|4MB|256MB|2GB|trap] H/W tablewalk events that fill ITLB or DTLB with translation for the corresponding page size. The “_trap” event occurs if the HWTW was not able to fill the corresponding TLB IC_mtag_miss, IC_mtag_miss_\ [ptag_hit|ptag_miss|\ ptag_hit_way_mismatch] I$ micro tag misses, with some options for drill down Fetch-0, Fetch-0-all fetch-0 counts nr of cycles nothing was fetched for this particular strand, fetch-0-all counts cycles nothing was fetched for all strands on a core Instr_buffer_full Cycles the instruction buffer for a strand was full, thereby preventing any fetch BTC_targ_incorrect Counts all occurences of wrongly predicted branch targets from the BTC [PQ|ROB|LB|ROB_LB|SB|\ ROB_SB|LB_SB|RB_LB_SB|\ DTLB_miss]\ _tag_wait ST_q_tag_wait is listed under sl=20. These counters monitor pipeline behaviour therefore they are not strand specific: PQ_...: cycles Rename stage waits for a Pick Queue tag (might signal memory bound workload for single thread mode, cf. Mail from Richard Smith) ROB_...: cycles Select stage waits for a ROB (ReOrderBuffer) tag LB_...: cycles Select stage waits for a Load Buffer tag SB_...: cycles Select stage waits for Store Buffer tag combinations of the above are allowed, although some of these events can overlap, the counter will only be incremented once per cycle if any of these occur DTLB_...: cycles load or store instructions wait at Pick stage for a DTLB miss tag [ID]TLB_HWTW_\ [L2_hit|L3_hit|L3_miss|all] Counters for HWTW accesses caused by either DTLB or ITLB misses. Canbe further detailed by where they hit IC_miss_L2_L3_hit, IC_miss_local_remote_remL3_hit, IC_miss I$ prefetches that were dropped because they either miss in L2$ or L3$ This variant counts misses regardless if the causing instruction commits or not DC_miss_nospec, DC_miss_[L2_L3|local|remote_L3]\ _hit_nospec D$ misses either in general or detailed by where they hit cf. the explanation for the IC_miss in two flavours for an explanation of _nospec and the reasoning for two DC_miss counters DTLB_miss_asynch counts all DTLB misses asynchronously, there is no way to count them synchronously DC_pref_drop_DC_hit, SW_pref_drop_[DC_hit|buffer_full] L1-D$ h/w prefetches that were dropped because of a D$ hit, counted per core. The others count software prefetches per strand [Full|Partial]_RAW_hit_st_[buf|q] Count events where a load wants to get data that has not yet been stored, i. e. it is still inside the pipeline. The data might be either still in the store buffer or in the store queue. If the load's data matches in the SB and in the store queue the data in buffer takes precedence of course since it is younger [IC|DC]_evict_invalid, [IC|DC|L1]_snoop_invalid, [IC|DC|L1]_invalid_all Counter for invalidated cache evictions per core St_q_tag_wait Number of cycles pipeline waits for a store queue tag, of course counted per core Data_pref_[drop_L2|drop_L3|\ hit_L2|hit_L3|\ hit_local|hit_remote] Data prefetches that can be further detailed by either why they were dropped or where they did hit St_hit_[L2|L3], St_L2_[local|remote]_C2C, St_local, St_remote Store events distinguished by where they hit or where they cause a L2 cache-to-cache transfer, i.e. either a transfer from another L2$ on the same die or from a different die DC_miss, DC_miss_\ [L2_L3|local|remote]_hit D$ misses either in general or detailed by where they hit cf. the explanation for the IC_miss in two flavours for an explanation of _nospec and the reasoning for two DC_miss counters L2_[clean|dirty]_evict Per core clean or dirty L2$ evictions L2_fill_buf_full, L2_wb_buf_full, L2_miss_buf_full Per core L2$ buffer events, all count number of cycles that this state was present L2_pipe_stall Per core cycles pipeline stalled because of L2$ Branches Count branches (Tcc, DONE, RETRY, and SIT are not counted as branches) Br_taken Counts taken branches (Tcc, DONE, RETRY, and SIT are not counted as branches) Br_mispred, Br_dir_mispred, Br_trg_mispred, Br_trg_mispred_\ [far_tbl|indir_tbl|ret_stk] Counter for various branch misprediction events.  Cycles_user counts cycles, attribute setting hpriv, nouser, sys controls addess space to count in Commit-[0|1|2], Commit-0-all, Commit-1-or-2 Number of times either no, one, or two µops commit for a strand. Commit-0-all counts number of times no µop commits for the whole core, cf. footnote 11 to table 10.2 in PRM for a more detailed explanation on how this counters interacts with the privilege levels

    Read the article

  • Mercurial Scenario

    - by richzilla
    Hi all, I have a scenario in mercurial, and i cant finad anything that would tell me how to solve it. Basically, i have a mercurial repository with numerous branches for stable, development, experimental features etc.... However, ive found a bug in a set of core application files that are common to each branch. Is there a way to modify these files, and then push the changes to the common files to all the other branches, without sending any other changes? any help would be appreciated.

    Read the article

  • Git - tidying up a repo

    - by Simon Woods
    Hi I have got my repo into a bit of a state and want to be able to work my way out of it The repo looks a bit like this (A1, B1, C1 etc are obviously commits) A1 ---- A2 ---- A3 ---- A4 ---- A5 ---- A6 ---- A7 ---- A8 / (from a remote repo) B1 ---- B2 --------------------------------- | \ \ C1 ---------------------------------C2 \ / D1 --- D2 --- D3 --- D4 --- D5 --- D6 Ideally I'd like to be able to remove all the revisions (with rebase?) on the B, C and D lines (I'm loathed to say branches simply because there are now no local branches on these lines except ref branches to the remote repo) and try to merge in the remote repo again, perhaps in a better way. I'd be grateful of any suggestions as to how to get rid of all these commits. Could I ask that any answers use revision SHA1s rather than branch names. I thought that somehow I'd be able to revert the merge into A7 but can't quite work out how to do it I hope that is sufficient information. Many thx Simon

    Read the article

  • ListBox Control in VB.NET 2008

    - by Tareq
    Hi all, I am currently working on a multi branch desktop based project using VB.NET 2008. My Admin want to see the list of currently working branches and not working branches. Additionally they want to know how long a branch is not working. To display the offline branches I first take a ListBox control named lstListBranch and then upon that control I take another ListBox control named lstListTime to display the offline time. I want to permanently hide the scrollbar for lstListTime control and want to scroll lstListTime when lstListBranch is scrolled. Can anyone help me in that purpose? Thanks in advance.

    Read the article

  • Git. Remote HEAD is ambiguous.

    - by Siegfried
    I checked the relevant thread but still can't solve this problem. When I typed "git remote show origin", I got * remote origin Fetch URL: xxxx Push URL: xxxx HEAD branch (remote HEAD is ambiguous, may be one of the following): development master Remote branches: development tracked master tracked Local branches configured for 'git pull': development merges with remote development master merges with remote master Local ref configured for 'git push': master pushes to master (up to date) I also checked "git show-ref", and I got: 3f8f4292e31cb8fa5938dbdd406b2f357764205b refs/heads/development 3f8f4292e31cb8fa5938dbdd406b2f357764205b refs/heads/master 3f8f4292e31cb8fa5938dbdd406b2f357764205b refs/remotes/origin/development 3f8f4292e31cb8fa5938dbdd406b2f357764205b refs/remotes/origin/master Here is the list of all branches I have by executing "git branch -a" development * master remotes/origin/development remotes/origin/master And this is what is in the .git/config: [core] repositoryformatversion = 0 filemode = false bare = false logallrefupdates = true ignorecase = true hideDotFiles = dotGitOnly autocrlf = false [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* url = xxxx push = refs/heads/master:refs/heads/master [branch "master"] remote = origin merge = refs/heads/master [branch "development"] remote = origin merge = refs/heads/development I and it seems that the remote development and master branch share the same node. How to solve this ambiguity problem? Thank you!

    Read the article

  • Removing part of a branch

    - by benPearce
    In our codebase we are using the following structure, using TFS / - Build - Development - Dev1 - Dev2 - Main - Releases - Rel1 - Rel2 The Development and Releases sections contain branches off main. The Build section sits outside the branching. Within each of the branches there is a section which should not have been included within the branching which I would like to move under Build. Is it possible to move this section out and remove its branching information? If I do a rename what impact might this have when creating new branches or merging?

    Read the article

  • SVN Feature Branch Method

    - by Seth
    I am getting a SVN server setup and will be using the feature branch method. I plan on having 1+ branches making up a release tag. How do I merge (?) multiple branches into the release tag, while still maintaining diffs and such? I've given an example of our workflow below. Multiple devs pull to local Create feature branch Commit to branch Use branch to build QA (Here is where my question starts) I need to have all the branches for the next build to be put into a build tag to be used to build Production

    Read the article

  • How can I relocate to a new repository address with TortoiseSVN?

    - by Jesse McGrew
    I have a working copy checked out from: https://oldserver/svn/myproject/branches/mybranch The server address has changed (actually, the repo was copied over to a new server) so I want to relocate my working copy to the new address: https://newserver/svn/myproject/branches/mybranch Note that only the address changed, not the path. But if I type that URL in TortoiseSVN's "Relocate" dialog box, I get the error "'https://newserver/svn/myproject/branches/mybranch' is not the root of the repository" ... well, of course it isn't, but so what? Then I thought maybe SVN wanted the repository root URL, so I tried giving it https://newserver/svn instead, but that produced the error "Relocate can only change the repository part of an URL". Are there any options besides backing up my changes and checking out a fresh WC from the new server?

    Read the article

  • SVN correct directory structure

    - by jax
    I followed this tutorial to setup SVN on my Fedora box http://www.ashishkulkarni.com/installing-subversion-on-fedora-linux/ It worked. However, there is no trunk, tags or branches when I set this up. In the tutorial he creates a sandbox project /svn/repos/sandbox Now I am assuming that all projects will go under repos /svn/repos/project1 /svn/repos/project2 When I view the project there are no trunk, tags or branches, I have not yet checked in any project, will these appear when I do that? As I understand all my files should go below the trunk. What are the tags and branches for? Just some clarification about the structure would be nice. Thanks.

    Read the article

  • Github without merging

    - by tfmoraes
    I have the following situation: A software hosted at github. 4 developers, each have her own fork in github. Each developer creates and develops using branches in her own fork. Given that we use branches to develop, we want to merge our branches (in our forks) to the upstream repo. How do I merge in github without using pull request? Is it possible to merge to upstream from my own fork? Thanks in advance.

    Read the article

  • Multiple svn projects into one git repository?

    - by trondgzi
    Hi, I have started to use git-svn for some of my work to be able to do local commits. This works great for projects that use standard svn layout. Recently I started working on a Java project that is split into multiple connected modules (20-25), and each module have its own root folder in the same svn repo with its own trunk/branches/tags. svnrepo/ module-1 trunk branches tags module-N trunk branches tags I have cloned each and every module with git svn clone -s /path/to/svnrepo/module[1-N]. The "problem" is that when I want to do git svn rebase on all modules i have to do it N times. I have tried to do git svn clone /path/to/svnrepo/ do avoid doing the rebase operation N times, but that leaves me with a directory layout that is the same as in the svn repo. Is there a way that I can track all the trunks of all modules in one git repo? So that I get a directory layout like this within my git repository: module-1 module-2 module-N

    Read the article

  • design pattern advice: graph -> computation

    - by csetzkorn
    I have a domain model, persisted in a database, which represents a graph. A graph consists of nodes (e.g. NodeTypeA, NodeTypeB) which are connected via branches. The two generic elements (nodes and branches will have properties). A graph will be sent to a computation engine. To perform computations the engine has to be initialised like so (simplified pseudo code): Engine Engine = new Engine() ; Object ID1 = Engine.AddNodeTypeA(TypeA.Property1, TypeA.Property2, …, TypeA.Propertyn); Object ID2 = Engine.AddNodeTypeB(TypeB.Property1, TypeB.Property2, …, TypeB.Propertyn); Engine.AddBranch(ID1,ID2); Finally the computation is performed like this: Engine.DoSomeComputation(); I am just wondering, if there are any relevant design patterns out there, which help to achieve the above using good design principles. I hope this makes sense. Any feedback would be very much appreciated.

    Read the article

  • How should I incorporate a hotfix back into a feature branch using gitflow?

    - by Mark Trapp
    I've started using gitflow for a project, and I have an outstanding feature branch as well as a newly created hotfix. Per the gitflow workflow, the hotfix gets applied to both the master and develop branches, but nothing is said or done about extant feature branches. Nevertheless, I'd like to incorporate the hotfix changes back into my feature branch, which as near as I can tell leaves three options: Don't incorporate the changes. If the changes were needed for the feature branch, it should've been part of the feature branch. Merge develop back into the feature branch. This seems to follow the gitflow workflow the best, but would cause out-of-order commits. Rebase the feature branch onto develop. This would preserve commit order but rebasing seems to be completely absent from the general gitflow workflow. What's the best practice here?

    Read the article

  • To branch or not to branch?

    - by Idsa
    Till recently my development workflow was the following: Get the feature from product owner Make a branch (if feature is more than 1 day) Implement it in a branch Merge changes from main branch to my branch (to reduce conflicts during backward merging) Merge my branch back to main branch Sometimes there were problems with merging, but in general I liked it. But recently I see more and more followers of idea to not make branches as it makes more difficult to practice continuous integration, continuous delivery, etc. And it sounds especially funny from people with distributed VCS background who were talking so much about great merging implementations of Git, Mercurial, etc. So the question is should we use branches nowadays?

    Read the article

< Previous Page | 4 5 6 7 8 9 10 11 12 13 14 15  | Next Page >